Create API to be consumed by Website and Mobile

Question

When designing an API to be easily consumed by different clients (web and mobile), should I create an end-point for each client?

For example, when trying to create an API for both web and mobile, I was thinking of the following:

Create the database
Create the API
Create the Website to consume the API
Create the Mobile version to consume the API

In other words, can I create a single API end-point such as this one:

http://site.ne/api/register - for both website and mobile

Or instead, I should create a separate handler for the website, say for eg.

http://site.ne/register.php - website
http://site.ne/api/register - mobile

I believe Facebook, Twitter, etc.. is doing the former. I just want to clear my doubts and fortify my understanding if this is the right thing to do.

Please lead me to some simple examples. If anyone has been buffled with the same before and came out victor, please share your solution.

The first pattern looks fine. I'm not an expert on this topic, but I think you're overthinking it. — Stephan Branczyk, May 26 '15 at 02:40
i made my resolve, im building an api-centric solution, as discussed here http://stackoverflow.com/questions/9453359/api-as-core-for-a-website-mobile-app?rq=1, also i've decided to put it simply, every solution is situational, solution a can solve problem a, and might (and not always) for problem b. as a solutions provider that is where the real job matters. it is our choice for the solution that will really matter. as Stephan commented. don't overthink it. — mirageservo, May 31 '15 at 15:40

score 0 · Answer 1 · answered May 26 '15 at 02:57

Your API should operate the same irrespective of the client. This is why, in part, RESTful APIs are popular. You are building one service for all your clients. Building your API this way makes it more maitainable and scalable (assuming it is stateless). This embraces the nature of the web.

To think about this, your client wants to interact with your service. It wants to retrieve data and send data back (using then HTTP verbs to signify intent). How this data is represented is the responsibility of the client and is independent of the service.

A web client can make Ajax calls to retrieve data and render in HTML. The HTML can be responsive to support multiple devices/screens. A thick client can also web calls and display it as it needs. Every time you need another client, build it. The service stays the same. Clients may also be other services - does that help?

If you believe that a URL represents a resource, then adding 'api' to your URL is an anti-pattern. If you're interested in reading more about REST, then I'd recommend Rest in Practice by Jim Webber. However you choose to build your API, I'd still recommend one interface that is unaware of the clients it serves.

Fadils · Answer 2 · 2015-05-26T03:27:33.867

By adopting REST architecture, then you can uniformly create APIs to be consumed by REST client.

This so-called REST client can be of web or mobile, with the usual JSON as its returned value.

Let's take Facebook's Graph GET user ID API (graph.facebook.com/{user-id} ) as an example:

We want to get some information for user-id: bgolub

GET https://graph.facebook.com/bgolubwill return the following JSON

  {
    "id": "15500414",
    "first_name": "Benjamin",
    "last_name": "Golub",
    "link": "http://www.facebook.com/15500414",
    "name": "Benjamin Golub",
    "relationship_status": "Married",
    "significant_other": {
      "id": "15500304",
      "name": "Megen Vo"
    }
  }

Then in the web (Javascript), you can do something like:

FB.api('/bgolub', function(response) {
  console.log(JSON.stringify(response));
  // do something more such as save the id to your DB
});

For Android, then you can create the REST client (say using Retrofit) for example:

public class MyClient {
  private static String URL_FEED = "https://graph.facebook.com";
  private static MyClientInterface sMyClientInterface;

  public static MyClientInterface getMyClient() {
    if (sMyClientInterface == null) {
        RestAdapter restAdapter = new RestAdapter.Builder()
                .setEndpoint(URL_FEED)
                .build();

          sMyClientInterface =   restAdapter.create(MyClientInterface.class);
    }

      return sMyClientInterface;
  }


  public interface MyClientInterface {
      @GET("/bgolub")
      void getBenGolub(Callback<Object> callback);
  }
}

The point is: One API end-point can and should be used by both mobile and web. Unless, you're returning different values, then no need to use more than one end-point for single functionality.

Create API to be consumed by Website and Mobile

2 Answers2