Design pattern for building a reasonably complex PHP web service [closed]

Question

I have just "finished" coding up a relatively involved web service in PHP. The code base is now a bit of a mess due to last minute requests, changes, add-ons, the usual.

I tried to code it as lightly as possible and in a manner that would maximise performance.

Therefore, I didn't use any frameworks like Zend or any ORMs like Doctrine.

I was wondering if there are any frameworks or design patterns that exist for the sole purpose of building APIs/web services in PHP?

I'm thinking of a refactor and I want to make sure now I know exactly what's involved I can build this thing properly.

Answer 1

I apologize in advance for the self-reference here to my own framework - there's no way for me to help you otherwise since I don't use anything else. I'm not advertising, since it's not public.

As I said in my comment, I think a good web front-end framework shouldn't mean it is a poor web service framework.

Because I was unsatisfied with the restrictive way any of the popular PHP frameworks (CodeIgniter, CakePHP, Kohana) processed requests, as well as their size, I wrote a framework that is designed for really only two purposes, process a request and determine an action to take, and then separate the code for that action from the view (response).

The design pattern I use is this:

1. All URLs are rewritten (mod_rewrite) and passed to your execution entry point.
2. Your entry point sets up paths that it will recognize and process. I.E. for a web service:
   • /users - User list
   • /user/* - User identified by the value where * is.
   • /user/*/delete - Delete the user
   • /posts - List posts
   • /post/* - View post *
3. Along with the path you specify a function, I.E. UserActions::saveUser to be executed if the HTTP method is POST. The reason it's only executed on POST is to enable output and input to have the same URL.
4. The path also specifies a view. This is the response body that will be sent to the browser. It can be rendered as straight PHP, or you could plug in a template engine. In the case of web services, all paths would probably use a single view that renders your data in the output format (JSON, XML, whatever). The view can be just a PHP method and is not required to specify a template file.
5. In the case of a web front-end, the view can have a parent view which wraps it (creating the page from the inside-out).
6. The last point is security. You can define a security type to be applied to any path. A security type just specifies what function (like SecurityManager::authorize) to check for authorization and if false is returned, it redirects to a path of your choosing.

The reasons I believe this design pattern works well for Web Services:

• Enables you to use a single-entry point, but can be used with multiple entry points (for optimization, if needed).
• No assuming that you want your URLs to match your Object Model, like most of the major frameworks do (a notable exception being Zend, as mentioned in the comments).
• Easily adapted to REST (instead of just checking for POST, check for other methods too).
• The removal of any HTML feels completely natural, since in this pattern the response is completely separated from processing.
• This can all be done in a few classes.