What are RESTful APIs?

REST stands for Representational State Transfer and is essentially a set of rules as to how two information systems communicate with each other. Using usual language, we have the client side and the server side. Clients are generally users of a service, so take for example: Piyush is using Google maps on his android phone to get navigation direction from SFU to Burrard Station.
Piyush’s Phone is the client and one of the computers in Google’s data center would be the server. The client and the server communicates through REST APIs. This essentially means that my phone and the server communicate in rather standardized ways. First,

1. The google map app on my phone sends a request to the google server in a standardized way. The burden of standardization is on the google map app. The app is requesting for navigation direction from SFU to Burrard. This is the resource we are looking for.

2. The server authenticates the client (NOTE the client) and confirms that the client has the right to make the request. Note that since I am simply asking for directions, it is not something to think about much. But if suppose, I was requesting to change the name of SFU to PFU on google maps, I would not have been allowed to do that. Hence, authentication is needed.

3. The server at its end crunches information and uses its navigation program (whatever it is) to fetch directions for me.

4. The server now sends response to the phone app. If everything is alright, I will be able to get to Burrard now. :)

Now this communication between client and server facilitated by REST API which imposes certain architectural constraints.

1. The client does not need to store any information about the server, nor does the server needs to store any information about the client. This is the property of STATELESSNESS. The request is complete in itself. This means that different client requests can be operated upon by the server independently of other requests. Note that this information can be used whether two systems are interacting in a REST framework. Take for example, interaction with ChatGPT. ChatGPT does store information about the different prompts (requests) and hence the prompts (requests) are not independent of each other. Hence, ChatGPT works on something different than REST API. Though it did not tell us clearly.

   

2. There is a UNIFORM INTERFACE by which clients request information to the server and how the server transmits information to the client. Google Maps working on my android phone would send the same request as my partner’s iPhone. If the resource requested is the same, then the request must be the same no matter who the client is. The resource is transmitted in a standard format and is referred to as the Representational State in REST. It is not necessary that the format in which the resource is sent is the same as how it was stored in the server. This ensures that requests are complete and completely specifies the resources to be fetched by the server. Further, using metadata, clients can decide to update or delete the resource or process the resource further. The resource also contains information about other resources (hyperlinks) required to complete a task.

3. There is a COMPLETE DECOUPLING of the client and server. They work completely independent of each other and the only interaction is via requests and responses.

4. LAYERED SYSTEM: The requests and responses can go through different layers and generally, the APIs are designed keeping in mind that the client and the server are not interacting directly but instead through different layers.

5. CACHEABILITY: Resources if possible can be cached at the server side to optimize client-server interaction.

6. CODE ON DEMAND: Resources are generally static but the server side can sometimes extend client capabilities by transferring software programming code to the client. So, for example while filling job applications, applications are verified using code extended by the server.

What are the benefits of using REST API?

1. First, the statelessness property of REST ensures that the communication is SCALABLE. The server does not have to store any client side information, and caching of resources also eliminates some client-server interactions.

2. Complete decoupling of the client-server interaction allows FLEXIBILITY. Any changes made in the client side does not affect how the server fetches resources in responses to a request and vice versa. So, the server components (like the navigation program) can be developed independently without worrying about the communication pathway.

What does the client side request contain?

The client requests have the following components:

1. URI (Unique Resource Identifier) - This is used to pin-point to the server which resource is requested by the client. URLs are generally used, which indicate the path to the resource.

2. Method: So after the server has gathered the resource, the HTTP method inside the request tells the resource what it needs to do with it. Some popular HTTP methods are:

   1. Post: Analogous to Create

   2. Get: Analogous to READ

   3. Put: Analogous to Update

   4. Delete: Analogous to Delete

3. There are more components like HTTP headers, Data and Parameters.

What does the server side messages generally look like?

The Server side response consist of the following components:

1. Status - Status line communicates success or failure. These are the most common codes:

   1. 2XX - Indicates success

   2. 4XX - Indicates failure on the client side.

   3. 5XX - Indicates failure on the server side.

2. Other than the status code, the response consist of the resource representation and the metadata of the response.

The references I have used for the article are:

1. https://aws.amazon.com/what-is/restful-api/

2. https://www.ibm.com/topics/rest-apis