The approach â API-centric app

To build the social network, we will use an approach called API-centric. First of all, for those who are unfamiliar with the term API, it is an interface that we build to expose functionality. By doing this, we allow other applications to interact with us. For example, a news website can expose an API to allow people to retrieve articles from their archive by specifying the date of the article, the author, and so on.

An API-centric application is an application that executes all functionality that make calls to an internal API. For example, if a user on our social network is going to post a picture, our app will pass the image and details of the user to the API to execute the actual steps needed to store the image and publish it on the user profile.

The API-centric architecture looks like the following figure:

As you can see, API is the central point and everything else is built around it. The web app, the mac app, and so on are the clients that consume API. Now, let's compare the lifecycle of a request between an app-centric approach and a traditional model.

As you can see, in the traditional model you made requests directly to the server. The server in this case contains the logic of the client and also the business logic. In the API-centric model, the request is made from the browse to the client app; this application can be on the same server as the API or on a separate machine. Then, the client app will issue a request to the API. After this, the request will go back to the client app and finally to the user. In this case, we are separating the code of the client app from the code of the API. The client app acts as a proxy for the API that has the business logic. Note that the image doesn't represent the time spent on the request.

Since the explosive increase in the usage of smartphones, an increasing number of web applications have ended up with an application on the phone. Some of themjust adapt the website to the phone screen size by removing or redesigning the interface, while others choose to build a native application that will run on the phone of the visitor.

The first benefit of this approach for our social network is that the core of the application is just an API and all the related clients will rely on it to use the functionality. This means we have a good separation of concerns, and we will have separated the business logic from the client logic. This will allow us to create a website to access the service and the possibility of building a native application for mobile phones or even a desktop program using the same API in future.

The second benefit is that the API is stateless; this means that the calls made to the API will not include anything about the session, and there is no session handling/management involved. This sounds wrong at the beginning but allows the developer to build a RESTful API that will not rely on the state of the user session or data stored on the session.

Note RESTful is the application of the REST architecture in web services. REST is an architectural style for designing networked applications. The idea behind it is to avoid complex mechanisms and use plain HTTP. A typical RESTful web service will use HTTP to do the four CRUD (Create, Retrieve, Update, and Delete) operations.

Another benefit is that the code can be tested further as you don't have to recreate the whole user session in order to test a functionality.

If we take a look at this approach from the server-side point of view, we can see some benefits; as we are separating the responsibilities of every component, we can assign different machines and resources to each of them. This way of organizing the servers allows us also to scale the components we need independent of the others.

One downside of the approach we can easily see is that if the API goes down, everything will go down and the clients will not be able to do anything.