This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

The move is pretty straightforward and makes a lot of sense as soon as you create more pages but you might have noticed a non-desirable side-effect... The LeapYearController class is always instantiated, even if the requested URL does not match the leap_year route. This is bad for one main reason: performance wise, all controllers for all routes must now be instantiated for every request. It would be better if controllers were lazy-loaded so that only the controller associated with the matched route is instantiated.

To help solve the issue, he uses the HttpKernel component and its "controller resolver" to figure out how to call the controller and pass it the correct parameters, but only when needed. A resolver object is created and that is used to instantiate the controller object. Sample "action" calls are included to fill out the basic controller (his "leap year" example) and the full resulting code is included both for the framework and the new object oriented controller.

For simple pages like the ones we have created so far, that's not a problem, but if you want to add more logic, you would be forced to put the logic into the template itself, which is probably not a good idea, especially if you still have the separation of concerns principle in mind. Let's separate the template code from the logic by adding a new layer: the controller: The controller mission is to generate a Response based on the information conveyed by the client Request.

He updates the template rendering to use an external method instead of doing it itself and updates the routing to include a "_controller" attribute pointing to the method. The full code for the updated version of the framework is included - a simple request/response with handling for a "leap_year" route.

Recently I had the idea to influence Controller Actions with annotations but discarded it with thoughts like "In PHP I will have to use reflection and some black magic to get this working which will have insane performance hits for my applications"... until I set everything up to see that it costs just 1-2ms in average per request without any form of caching.

He includes a few bits of code to show a simple annotation example (setting a layout) and the controller plugin that performs the translation. In his case, it's hard-coded to look for the "@layout" annotation in the docblock comment, but it'd be relatively trivial to extend it to a more full-featured version.

Rather than attempt to build and maintain multiple versions of the Web application in order to accommodate the diverse array of challenges and advantages presented by each device type, developers are increasingly embracing a unified approach which allows them to manage a single server-side code base which communicates with multiple client-specific interfaces by way of a RESTful Web service. The Zend Framework's Zend_Rest component offers PHP developers with an incredibly straightforward approach to building RESTful Web services.

He shows how to set up some internal RESTful routing (with the help of Zend_Rest_Route) and create a simple controller that responds to several of the major HTTP request types - POST, GET, PUT, etc. In his simple example, he shows how to update a basic TODO list with a POST and the JSON response that would follow.

If you've ever built a Zend Framework MVC app which makes AJAX calls, you may have noticed that if an error occurs, you'll get a chunk of JSON followed by the HTML for the error page. If you've built a layout, you'll get all of that back to. This is fine if your users hit the page in the browser but it can cause problems with your JavaScript being able to correctly decode your JSON.

The fix is pretty simple, though, and only requires that you add the error handling action to the Ajax context to force it to drop the layout and any other HTML that might come along with the view. He includes a bit more code to have the error handler include the exceptions and pass them out to be included in the JSON response.

In fact, it is the advised best practice for controllers in shared bundles. When you do, you will no longer have access to these useful methods, in this post I am going to look at how to accomplish the same tasks without them. I have created a simple controller for some basic form interaction with a model which uses the base controllers methods. I am going to go through how to change this to a service which does not extend the base controller.

He starts with his "TestimonialController" that does some of the basic CRUD operations on the testimonial information. He shows you, step-by-step, the refactoring needed to stop using things like the default controller helpers (each with replacement code). With those removed, he can move to extend "ContainerAware" instead of "Controller", make the controller a service and doing some dependency injection for needed resources.

Later today, I will release Symfony2 beta2. But first, I wanted to talk about a big change that landed into master yesterday. As you might know, Symfony2 uses annotations for Doctrine mapping information and validation configuration. Of course, it is entirely optional, and the same can be done with XML, YAML, or even PHP. But using annotations is convenient and allows you to define everything in the same file.

Two new bundles were added, SensioFrameworkExtraBundle and JMSSecurityExtraBundle, that let you use annotations in the controller for configuration. Examples of this new feature are included in the post giving the configuration settings a more "native" feel.

Here's a counterpoint to the currently popular view of "fat controllers are bad", and the current fad of everyone and their cousin implementing service layers: You don't need one. Fat controllers are okay too.

He starts by explaining the "why you don't need a service layer" part, mentioning that keeping it in the controller keeps things simple and keeps your code from having to go through extra hoops just to work correctly. He also points out that, just because he recommends "fat controllers" doesn't mean he's advocating code reuse. In fact, just the opposite:

It's fine if you code your things in the controllers, but there comes a point when you should stop that. The moment you realize you're duplicating your code, stop and refactor. This is one of the very basics of software engineering: Avoid duplication by creating functions and classes.

Thanks to a discussion on the Zend Framework mailing list I learned about a new feature, a feature that allows for grouping action controllers in subdirectories! Well, this is more of an unknown and undocumented feature than new, as it is the part of the framework for at least 3 years. Why am I so hyped about this? Because it allows for better code organisation on larger projects. Heck, it might be useful on smaller ones too.

He gives an example of how it might be laid out and a few helpful hints he learned when trying it out:

• The subdirectory separator in the URI is the underscore and not the slash.
• The subdirectory name is uppercase: Subdirectory, not subdirectory. In the URI it's lowercase.
• The view directories for these subdirectories are lowercased, and not uppercase.