PHP - Internal APIs/Libraries - What makes sense?

Posted by Mark Locker on Programmers See other posts from Programmers or by Mark Locker
Published on 2012-07-12T13:15:48Z Indexed on 2013/11/06 10:11 UTC
Read the original article Hit count: 224

Filed under:
|
|
|
|

I've been having a discussion lately with some colleagues about the best way to approach a new project, and thought it'd be interesting to get some external thoughts thrown into the mix.

Basically, we're redeveloping a fairly large site (written in PHP) and have differing opinions on how the platform should be setup.

Requirements:

The platform will need to support multiple internal websites, as well as external (non-PHP) projects which at the moment consist of a mobile app and a toolbar. We have no plans/need in the foreseeable future to open up an API externally (for use in products other than our own).

My opinion:

We should have a library of well documented native model classes which can be shared between projects. These models will represent everything in our database and can take advantage of object orientated features such as inheritance, traits, magic methods, etc. etc. As well as employing ORM.

We can then add an API layer on top of these models which can basically accept requests and route them to the appropriate methods, translating the response so that it can be used platform independently. This routing for each method can be setup as and when it's required.

Their opinion:

We should have a single HTTP API which is used by all projects (internal PHP ones or otherwise).

My thoughts:

To me, there are a number of issues with using the sole HTTP API approach:

  1. It will be very expensive performance wise. One page request will result in several additional http requests (which although local, are still ones that Apache will need to handle).

  2. You'll lose all of the best features PHP has for OO development. From simple inheritance, to employing the likes of ORM which can save you writing a lot of code.

  3. For internal projects, the actual process makes me cringe. To get a users name, for example, a request would go out of our box, over the LAN, back in, then run through a script which calls a method, JSON encodes the output and feeds that back. That would then need to be JSON decoded, and be presented as an array ready to use.

  4. Working with arrays, as appose to objects, makes me sad in a modern PHP framework.

Their thoughts (and my responses):

  1. Having one method of doing thing keeps things simple. - You'd only do things differently if you were using a different language anyway.

  2. It will become robust. - Seeing as the API will run off the library of models, I think my option would be just as robust.

What do you think?

I'd be really interested to hear the thoughts of others on this, especially as opinions on both sides are not founded on any past experience.

© Programmers or respective owner

Related posts about php

Related posts about object-oriented