I’m surely getting old… I remember back in the day when PHP websites were still… well… fully PHP and JavaScript was this little bit of nasty add-on that you didn’t want to do because IE6 would screw it all up 🙂
I’ve recently been doing some PHP&JS work and was playing around with jQuery! What a revelation! Back when I created my CCMS (http://git.mrman.de/ccms), I had to use iframes that would load pure JavaScript to get the “interactive” part done. Life is so much simpler these days, which leads me to the purpose of this post.
I am currently studying for my Systems Architecture Exam and thus am looking at the architectural aspect of things more closely these days. And given my latest web project (http://git.mrman.de/simpleStock) I became quite fond of what I would describe as an API based architecture. It’s probably not new and has a way more fancy name out there, but I wanted to share my 2 cents non-the-less.
The Architecture
In (a/my) traditional PHP setup, every page would be served more or less including PHP coding that read & formatted data from a database or somewhere. This was fine back then, but given the ease that jQuery enables AJAX calls and its powerful front-end possibilities, I have started to move all my PHP backend coding into a single file I call api.php.
Now this one file is obviously not all the logic, but it provides a gateway for all functionality that I want to be able to achieve. Essentially, it redirects the various GET/POST/… requests into a variety of PHP classes that actually do the requested job. In another project, I even went as far as to redirect the resource path into the api.php via apache modules, so that you could call something like /songs/1/tags and get a list of tags for song 1….
All communication in and out of the api.php is done via JSON.
On the front-end, essentially static pages are served (-Â they are not completely static since I use PHP to include the same menu everywhere but almost- ), and AJAX requests get the data via the api.php interface.
Pros and Cons
This allows the following (in my opinion really cool) things:
- Beautiful View vs. Model abstraction with a little controller on both sides of the infrastructure
- Utilizing HTTP the way God (or Roy Fielding) intended it to be. Error codes on errors, PUT, POST, GET, DELETE requests against resources, the whole shebang
- This is really easy to test (manually & automatically)!
- Re-usability for other applications
- Cleaner code
- Less data transfer
- One can switch away from PHP easily 🙂
Of course there are disadvantages, the biggest being that the browser needs JavaScript and the speed and performance to be able to handle it.
Also, the api.php will stand by itself, therefore the design needs to anticipate all kind of inputs and make sure they are handled gracefully. However, I consider this actually and advantage since it makes for clean and robust code!
Things I haven’t properly tried yet
- Authentication. So far I have used the standard Apache authentication module (actually, the mysql backed one – another blog post is to follow about that), but I would need to see how this plays out with the API and different access levels. However, I think it can be done and it would actually mean that the system would follow overall HTTP authentication rather than a PHP specific one which again, is AWESOME!
- I would like to see how this thing scales in a larger environment. It would probably be pretty good, given that the front-end is essentially static (so you could almost use a CDN) and only the api.php hits the server
- This is not directly related to this architecture, but more general. I’d like to try and introduce proper locking mechanisms in a stateless world. Not sure how to go about this yet (read a couple of promising approaches though), so stay tuned 🙂
Anyway, I better get back to studying!