1

I have a RESTful API that allows retrieval of data through requests such as GET http://example.com/users/id/1 (Coded following this tutorial).

The code igniter controller looks like this:

class Example_api extends REST_Controller {

function user_get()
{
    $data = array('returned: '. $this->get('id'));
    $this->response($data);
}

This API was written specifically for the reason that I should be able to access the same code logic from the web frontend as well as mobile apps etc. Now, the mobile app is easy to write but I want to find the strategy for using the API from the web site. The website is essentially sitting on the same server that offers this API and it does not seem right to me to make an HTTP request to the API from code and go through the network again.

So, the question is, how do I use the API from the php code in the same site without going through the network.

  • If you could replace example.com with a reference to a Unix socket, you could avoid the TCP/IP stack altogether. I wonder if it's worth doing, though: unless your application server layer is very low latency, the overhead of going through the network layer locally may be negligible. – 9000 Mar 31 '14 at 7:23
  • Ah, so you suggest just using the API from the site as I would from the mobile? That would definitely make my life easy. – recluze Mar 31 '14 at 7:38
  • In an ideal world you don't think about hosts at all; you only think about services and call them by canonical names. It lets you scale out easily, etc. Unfortunately, there are non-locality penalties. But your case is strictly local. – 9000 Mar 31 '14 at 10:57
2

It sounds like both the API and the website share a common language (PHP). In such a scenario I often find that the functionality used by the API can often be abstracted out into a less API specific object that other solutions (like the website) can also utilize.

This object would serve as a shared interface for the website and the API. Very little functionality then needs to live in the API code as it is simply operating as a translation layer between HTTP requests and the object.

It also saves the website from having to make network calls to an API and allows it to interact with the object more naturally.

If your API's functionality is relatively simple this runs the risk of being an over-architected approach so you'll need to consider if this is necessary and maintainable in your specific situation.

0

For the moment, as 9000 said, I can't see any real reason to take another approach. However, if design is your main goal, perhaps you should separate your web app from your API server? That way both your web app and your mobile and native apps connect to a uniform REST implementation. Speed at that point is all on your API server, and REST pretty much expects HTTP otherwise it wouldn't be as simple as REST.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.