PHP - Internal APIs/Libraries - Your Thoughts Please!

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 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. Please respond if you have an opinion :slight_smile:

Hi,

I would encourage you to read this 4 part blog series on REST… This may be what your colleagues are basing their position on (perhaps just as a buzz word or maybe a greater understanding of what REST can do and how PHP applications are structured using it.

Then you might be interested in reading about Building a Domain Model

This may also interest you; Encapsulating Common Implementation in Multi-Tiered Systems

Another is Decoupling Interfaces from Implementation – Using Separated Interfaces

I don’t have time to comment on your versus your collegues thoughts at this time. But it helps to define an Architecture. Luckily many developers before you and in the current day have developed for patterns to improve application design. A really well designed large application is Symphony2; you can download it and go through their classes and see how nicely everything works together.

Will check in on Monday (Eastern Time) to see what’s up.

Regards,
Steve

First, exposing a restful API and exposing the same service layer as a native [for lack of a better term] API aren’t mutually exclusive. A good service stack will just be serializing objects to send down the wire in any case, no reason you can’t just make use of the same service calls without the serialization and travel over HTTP angles.

Second, HTTP API on a local, fast network is likely fast enough for your purposes. It is working for Twitter, Facebook, Amazon and lots of other names you know.