API 101: Backdoor to Backend

By Aman Sharma

A Quick Dive Into The World of APIs, And How APIs Drive Applications

In this digital age, we are surrounded by applications that we pretty much rely on to facilitate almost all our day to day needs. Is reading the news, getting yourself updated with the happenings around the world the first thing you like to do when you wake up? Well, there are a bunch of news applications like Google News and Inshorts for that. Running late and wanna grab a cab to work? You can quickly summon cab right at your doorstep with the Uber app! Hungry but don’t wanna cook? There are a bunch of food ordering apps for that as well. You can just whip out your phone and order your grocery right from the comfort of your home without having to carry those heavy grocery bags and roam around stores.

But why are we discussing this? The point is that today we have these very convenient apps that can do almost everything for us. But that’s from the user perspective. To a software developer, there’s more to that. The first question that arises is — How are these applications made?

To answer this, we can take a look at the 3-Layer Application Architecture. The 3-layer application architecture is a well-established software development architecture that breaks down a software into 3 logical and physical computation layers, viz. the presentation layer (refers to the client-side application, i.e., the app that the users actually see and interact with), the application layer (refers to the application component that handles all the business logic) and the data layer (refers to the component that stores and handles all the data within the application).

Now, these three individual components work together to make a usable application.

• The user interacts with the client-side (also known as the frontend) application, making some sort of request.
• The application layer processes this requests. If any data is generated or altered while processing this request, that is maintained on the data layer.

NOTE: Often, the application and data layer combined together are referred to as the server-side (or backend) application.

• After the request is processed by the backend, a response is sent to the frontend application.

But now, another question arises. The one that we’re going to specifically answer in this guide — How do the frontend and backend communicate back and forth with each other?

Well, here comes into play the concept of APIs.

What is an API?

API is an acronym for Application Programming Interface. As the name suggests, it is an interface of some sorts. To be more precise, APIs allow cross-platform and inter-device communications.

• Software-to-software communication: Earlier, we discussed how an application can be broken down into client-side and server-side components. These components exchange back and forth a set of requests and data responses. This communication interfacing is facilitated behind the scenes by APIs. The client sends an API request to the server, the server processes the request, and then returns an API response to the client.
• Platform-independent communication: Since APIs act as an effective communication mechanism between the client and the server, this means that both the client and the server can be based on entirely different tech stacks and yet manage to work together. For example, your frontend application can be written in JavaScript, and your backend can be written in Python. APIs generally have a standardized request and response structure that almost all programming languages support.
• Reusability of code: APIs promote code reusability. Let us understand it like this. Instagram has both a mobile application, as well as a website. Now, we have two types of clients in case of Instagram, but only one backend that handles requests from both the web client as well as the mobile client. Both these clients make requests to the same backend server using APIs. Thus, there is no need to implement a separate backend for both mobile and web.

So now that we have a brief understanding of what APIs are, let us dive deeper and take a look at the different kinds of APIs available.

Types of APIs

There are primarily three kinds of APIs, based on the services they provide. These are as follows:

• Local API: These are OS APIs that provide services to the application programs, such as microphone access, camera access, or requesting data from DB service, etc.
• Program API: It is based on Remote Procedure Call (RPC) technology that allows remote program execution from another server. These APIs simply allow executing scripts or programs on a remote server or device.
• Web API: Web APIs, also known as web services, allow applications or devices to communicate to each other via the World Wide Web, using HTTP architecture. When it comes to building applications that involve a client-server architecture, we primarily use web APIs.

Now, since the focus of this article is to familiarize ourselves with how applications are built, we are going to focus specifically on web APIs.

Web APIs can further be broken down into several classifications like SOAP (Simple Object Access Protocol), REST (REpresentational State Transfer) APIs etc. As of today, a majority of applications around the world predominantly use the REST API architecture for client-server interactions, due to the ease of implementation. Since REST has become the industry standard, in this article, we are going to discuss REST APIs.

What are REST APIs?

As we saw earlier, REST stands for REpresentational State Transfer; also known as RESTful web services. It is a standardized API architecture that allows cross-platform and inter-device communications over the HTTP network protocol.

A typical client-server interaction involves primarily four kinds of operations, namely:

1. Create: The create operation via an API request pertains to creation of a resource on the data layer of the backend. For ex.- In a TODO application, a create API request can be used to create a TODO item in the database.
2. Read: The read operation can be used to fetch data from the database. This data can be a single resource of a type, a batch of resources of a single type, or a collection of resources of different type based on the client’s request and implementation of resource access on the backend. Taking the example of the same TODO application, a read request can be used to fetch all the TODOs created by a user.
3. Update: An update operation can be performed to update the data associated with a particular resource in the data layer. In our TODO application, the update request can be used to update the TODO task.
4. Delete: As the name suggests, the delete operation can be used for deletion of resources. For our TODO app, delete requests can be used to delete a TODO object from the TODO list.

These operations are collectively referred to as CRUD (Create, Read, Update, Delete) operations. For any application, these are some of the most basic operations a user can perform. To put it in layman’s terms, when a user is interacting with an application, they are either accessing some data, or some data is being created or manipulated. REST APIs act as the intermediary step between the frontend and backend of the application, allowing CRUD operations to be performed within an application.

Now, we read earlier that because of how APIs are implemented as a communication channel between the client and the server, both the client and the server can be written using entirely different programming tech stacks. However, there has to be a standardized, language agnostic mechanism so that the client and the server can interact via the API. For this, REST APIs use JSON-based messaging protocol.

JSON stands for JavaScript Object Notation. It is an open-standard file format and data interchange format which is human readable in nature. Data is transmitted using JSON in a key-value pair and array format.

The following diagram demonstrates a typical client-server interaction.

• The client sends an API request to the server over the HTTP protocol. This request is in the JSON format.
• The server parses this API request, processes the request, and then sends an API response back to the client, which is again in the JSON format.
• The client can parse the JSON response object to render it.

As you can observer, since the intermediary communication channel is standardized, hence the client and server can operate independent of each other in terms of platform and implementation.

Another important characteristic of REST APIs is that they are stateless. This means that each request from the client to the server must contain all of the information necessary to understand and complete the request. The subsequent requests aren’t dependent on the previous requests.

With this, we have completed some of the theoretical concepts regarding APIs and what are the characteristics of REST APIs. And all this brings us to the most important part of all.

What Does an API Request Look Like?

As we discussed earlier, REST API calls are stateless in nature, which simply means that with each API request, we need to send all the data that is required in order to process the request. This data involves the type of operation that is to be performed, information regarding user authentication, the resource that is to be accessed via the API, along with some additional parameters that might be required to process the request.

Based on these requirements, a REST API request can be broken down into 4 components:

Resource Path

This is the path to the resource that is to be acted upon via the API request. A resource can be thought of as an object or entity within the database. The resource path is a mapping to an entity within the database. Let’s continue with out example of a TODO app. One of the API endpoints can be used to fetch the list of all the TODOs of a user. The URL of the endpoint looks like this:https://mytodolist.com/todos/

Here, https://mytodolist.com is the domain of the website. /todos/ is the resource path to the TODO objects.

HTTP Verb

As we discussed earlier, an API request has to specify what kind of CRUD operation it is intending to perform. For this, we specify an HTTP verb within our API call. The simplest way to understand HTTP verbs is that these are words that tell the server what action to perform on the particular resource.

There are a bunch of predefined and standardized HTTP verbs, however the most commonly used ones are as mentioned below.

• POST: Used to create a resource object
• GET: Used to perform the read operation on the resource
• PUT: Used to perform update operation
• DELETE: Used to perform delete operation

Request Body

Request body can be used to specify some of the additional parameters that can be required to process a request. For example, in our TODO app, in order to create a TODO object, we have to specify the task. Similarly, in order to update a TODO object, we need to specify the new task that will be replacing the original task in the TODO list, along with the ID or the task that has to be modified. In our API request, we will have to send this information.

Generally, we need to specify a request body for POST and PUT requests. GET requests don’t have a request body.

Also, the request body uses JSON format to send the request data in the form of a key-value pair object.

Request Header

While the above 3 components are generally enough to make a REST API request, sometimes we need to specify some additional details along with the API request as well. Take an example of user authentication.

In our TODO app, we might have a bunch of users, each of them having their own TODO lists. We have to ensure that first of all, only the authorized users can create, read, update and delete TODOs. Then, we also need to ensure that one user can’t access another user’s TODOs. To guarantee these requirements, we need to implement some sort of authorization on the API endpoints, that determines whether an authorized user is making the API request, and whether the resource actually belongs to the user.

While we won’t go deep into the authentication strategies, however, just for the sake of information, we send authentication information in the request header, generally in the form of a unique token.

All these components come together to make an API call.

Let us look at some example API calls, made using cURL:

curl — request GET \

— url https://realstonks.p.rapidapi.com/TSLA \

— header ‘X-RapidAPI-Host: realstonks.p.rapidapi.com’ \

— header ‘X-RapidAPI-Key: 1ca406921amsh21f2341da9178c3p1a7dd9jsn5d319166bd9e’

The above given is a GET API request. We specify the HTTP verb using the — request flag. The — url flag is used to specify the request path. Then the headers are specified using — header flag.

curl — request POST \

— url https://hotel-price-aggregator.p.rapidapi.com/rates \

— header ‘X-RapidAPI-Host: hotel-price-aggregator.p.rapidapi.com’ \

— header ‘X-RapidAPI-Key: 1ca406921amsh21f2341da9178c3p1a7dd9jsn5d319166bd9e’ \

— header ‘content-type: application/json’ \

— data ‘{

“hotelId”: “102061485”,

“checkIn”: “2022–07–01”,

“checkOut”: “2022–07–02”

}’

The above given is a POST request where we can see the example of request body being specified, using the — data flag.

The implementation of how an API request is made might differ from one programming language or utility tool to another. However, the key components of the API request are going to remain the same, i.e., the HTTP verb, request URL or request path, a request body and request headers.

Now that we know what a API request looks like, there’s just a final component remaining in the API request-response cycle that we need to understand — the API response.

What Does an API Response Look Like?

An API response is the response that the backend returns to the frontend after the API request has been processed. A response should tell the client whether the request was successful or not, and if successful, it should return the requested data, or an appropriate acknowledgement message to the client. In case the request was unsuccessful, the client should receive a relevant error message.

Based on these requirements, an API response can be broken down into two parts, as discussed below.

Response Body

The response body consists of the requested data (in case of a GET API request), or an appropriate acknowledgement message in case of other API request types. In case of a failed API request, the response body consists of the appropriate failure message that specifies why the API call to the server failed.

Response Status Code

The API response contains a response status code that helps the client determine whether the request was a success or failure. These status codes have been standardized for the HTTP protocol, and can be broadly divided into 5 classes — 1xx→ Informational, 2xx → Success, 3xx → Redirection, 4xx → Client Error, 5xx → Server Error

Some of the common status codes are as mentioned below.

• 200 — OK. The request was successful.
• 204 — No Content.
• 301 — Moved Permanently.
• 400 — Bad Request.
• 401 — Unauthorized.
• 403 — Forbidden.
• 404 — Not Found.
• 500 — Internal Server Error

Conclusion

With this, we come to an end of this article. Just to summarize, we understood what APIs are, and how they function to allow communication between devices and applications. Finally, we studied REST APIs in depth — how an API request-response cycle works.

Obviously, APIs are just a foundation, or a backdoor, into the immense world of software development (backend, to be more precise) as the title suggests.

You can follow me to read more such interesting concepts, and we even might go deeper into exploring backend development.