In a new post to the SitePoint Business & Marketing blog Chris Ward asks an interesting question that applies to both the business side and development: do you need an API?.

API stands for ‘Application Programming Interface’ and as the name implies, creating one is a technical process. This article will talk very little about how to create an API as there are a myriad of methods to undertake that. This article aims to focus on the business side of APIs and supply advice for non-technical folk. [...] You may be a forward thinking individual inside of an organizational structure that doesn’t share your views. How can you convince others around you that having an API may be good for your business?

He talks about three of the main kinds of organizations out there that usually have APIs including government, civic and science organizations and most other online services that integrate them into their core services. He also tries to help you answer the question for your own organization by listing some of the positives it can provide as well as some of the negatives that could balance them out. He ends the post with one final recommendation if you do choose to implement an API: "Don't reinvent the wheel".

On the Symfony blog today they've posted a use case that talks about Symfony meeting some high performance needs and some of the development that was done to make it happen.

For most people, using full-stack frameworks equals slowing down websites. At Octivi, we think that it depends on correctly choosing the right tools for specific projects. When we were asked to optimize a website for one of our clients, we analyzed their setup from the ground up. The result: migrate them toward Service Oriented Architecture and extract their core-business system as a separate service. In this Case Study, we'll reveal some architecture details of 1 Billion Symfony2 Application. We'll show you the project big-picture then focus on features we really like in Symfony2. Don't worry; we'll also talk about the things that we don't really use.

They start with some of the business requirements they needed to meet and how it influenced the overall architecture of the application. They cover some of the things they liked the most about using the framework including bundles and using the EventDispatcher component. Some example code is also included for the custom handling they created for routing, CLI commands and request handling. There's also a mention of using the Profiler, Stopwatch and Monolog trio to do some performance analysis on the resulting application. Finally, there's a brief mention of some of the tools they're not using and why (two of them): Doctrine and Twig.

In the most recent post to his site Brandon Savage suggests that choosing and using a framework for you application isn't even needed.

Looking through the list of PHP frameworks can be daunting. Zend Framework. Laravel. Cake. Symfony. Picking one and learning it can seem like the most important design decision you'll make. And yet, picking a framework is actually one of the least important decisions you face. In fact, you don't need a framework at all.

He starts with a brief history of (PHP) frameworks and talks about their evolution from a set of common libraries out to the full stack versions we have today. He moves on to the "PSR and Composer era" where the lines started to blur a bit. With the renewed emphasis on packages in an easy to install method, frameworks started to become less important.

Now, instead of having a bunch of siloed frameworks that can't work together, there are (supposedly) standards for how they can integrate. An added bonus is that library creators can follow the same standards, making their libraries compatible with all the frameworks that implement the PSR standards.

You can read a rebuttal to this post from Anna Filina on her site.

In an effort to get some real feedback from the community about the state of PHP and what they think it needs, Sean Coates asked on Twitter for people to respond with their suggestions as to what could help make PHP better and what the project itself needs.

PHP's intentional stagnation is eating away at me. I'm working on a list of things I think #PHP needs. What's on your list? Tag it #phpneeds

There's been a great response already with suggestions ranging from features the language itself needs out to suggestions for those running and participating in the project. Keep this Twitter search bookmarked to see some of the great discussion.

New on his blog Cal Evans looks at an interesting topic that several developers out there might not think about - is WordPress training needed?.

Has WordPress become so simple that it requires no training? Honestly, if you are a PHP developer already, yes, it is that simple. Ok, so the code isn’t OO and that drives a lot of purists up the wall but at the end of the day, it’s functional and that’s what is important. Like PHP itself, WordPress is a tool that lets you get the job done.

He talks about the different sides of the same coin - the PHP developers that need to get their hands into WordPress' code but need a little guidance and the users that need to understand the interface that this code provides to get the most out of their sites. He also points out a few resources where you can start on your quest to WordPress mastery like Mitch Canter's blog and Aaron Brazell's blog as well as videos on lynda.com.

Fabien Potencier has posted another article about dependency injection and the Symfony service container. In this part of the series he looks at the "need for speed" - reducing the need for the XML/YAML parsing of the same information on every request via a new tool, the PHP dumper.

With the introduction of the XML and YAML configuration files, you might have became a bit sceptic about the performance of the container itself. Even if services are lazy loading, reading a bunch of XML or YAML files on each request and creating objects by using introspection is probably not very efficient in PHP. [...] How can you have the best of both world? That's quite simply. The Symfony Dependency Injection component provides yet another built-in dumper: a PHP dumper.

The dumper lets you convert the service container into regular PHP code (expanding the container's functionality out into a Container class based on the XML/YAML configuration.

Brandon Savage has a new look at an old problem in the PHP community - the importance of a developers' understanding of marketing in applications.

Technical people seem particularly bad at marketing effectively. I think this is because we’re fact-oriented, focused on the features and neat ideas our products include. We’ll spend pages and pages talking about the cool things that our tool or application can do. And then we’ll wonder why our client didn’t buy it. Why do we do this? Because we forget that marketing isn’t about features it’s about meeting needs.

He points to the hierarchy of needs as an example of what really has to be considered when developing software. The further down the pyramid you and your software can go, the more effective your marketing can be. An application can do everything under the sun, but if it doesn't do what the customer wants, it'll be tossed aside.

Following up on the previous part of his dependency injection series (the first part), Fabien Potencier has come back with this second look at the development technique asking if you really need a dependency injection container in your scripts.

In the first installment of this series on Dependency Injection, I have tried to give concrete web examples of Dependency Injection in action. Today, I will talk about Dependency Injection Containers. First, let's start with a bold statement: Most of the time, you don't need a Dependency Injection Container to benefit from Dependency Injection.

A dependency injection container is a wrapper around classes/libraries that need certain types of objects and settings to make them work correctly. This wrapper gathers together the information the object inside needs automatically without the user of the library having to worry they've missed something. Several code examples are included showing an application both with and without the container.

On his blog today, Stefan Mischook compares two of the popular component libraries out there - PEAR and the Zend Framework (yes, it can be considered a grouping of components too).

Now that the Zend Framework is ready for 'prime time', I’ve been considering the Pear framework with regards to how it now fits in the PHP world.

He suggests that not could both be considered component libraries, but might also both be frameworks (based on a definition that a framework is a "consistent set of components that are designed to work together in a unified manner"). He also asks about the need for something like PEAR now that the Zend Framework has come along, getting Jonathan Lebensold's opinion too.

Piggybacking on a recent proposal for traits in PHP, Lukas Smith has suggested something that could help make the organization of these sorts of contributions (and their "staying power") a bit more likely to happen - an official PHP.net wiki of sorts.

As such I really like what Stefan has done with his Traits proposal. Very nicely done. [...] Right now the RFC documents are hidden away in the unwieldy mailinglist archive and Stefan's private homepage, which could disappear any day. Of course there are also the various web archives, but what would be nice to have is a PHP.net wiki.

He notes that not only would this help protect information like this from dropping off the face of the web but it might also pave the way for some other changes to be made to the language (and to provide a space where everyone can share their ideas). He specifically mentions his wants for an array_merge_replace and a change to file_exists.