What is Rest API?

What's an API?

An Application Program Interface referred to as an API is an architectural style that defines a set of rules to create web services that enable different programs to communicate with one another, transmit data, and integrate with them.

Let’s break this out with the same real-life example.

Here the person ordering the food, you are the client. The waiter is the API, the kitchen/chef is the server, and the food is the resource requested by the client. When the client needs some resources, it requests them to the server via the API.

REST

Now, that you know what is an API Another question will be pounding in your head, What is a REST API? And how is it different from regular APIs REST has its full meaning as REpresentational State Transfer.

An API can be called REST-FUL if it satisfies the REST architectural principles as stated below.

What does Representational state mean?

If you need to move on any further in this article, it is essential for you to understand this jargon, Representational State. Consider a social media platform that you use daily, say Instagram. On Instagram, you share the amazing moments of your life as pictures, videos as a post or a story, and you also comment, like and share on your friends’ posts. Of course there are other things, but they are not needed for this article.

So let’s now dive a layer deep into the working of the Instagram. The photo, the location, the caption, and others that you share as a post are known as a resource. These resources are stored on the server. So, when you open Instagram and scroll through your feed, you are requesting to the server for these resources. The server receiving the request will not just share a copy of the resource back to you. If you are wondering why can’t it just send a copy over, what trouble is it going to cause.

Just for a second, think that the servers are responding to the request with a copy of the resource. In the case of an Instagram post, there will be likes and comments; and likes are a pretty big thing on a platform with professional influencers, Right? So what would it take for someone to just change the like count of a post to 1 million and sent the updated resource back to the server. This should not be allowed, Right?

This totally spoils the integrity of the platform. So in order to avoid these unnecessary troubles, we share only the representation state of the resource.

When the server is requested for a resource, it shares the representation state of the resource to the client. The representation state consists of all the properties of the requested resource, and all the operations that can be performed on the resource. In the Instagram example we have considered, the pictures or the videos posted, the caption, the location, the persons tagged in them, the number of likes, and the comments are the properties of the post i.e. the resource.

The operations can be share, comment, save to your profile, and like or dislike (remove your like), because every user is given only one like so at any moment there can only be either like or dislike. The server will share these properties and the operations allowed for the user, as a response when requested for a resource, in a format that the client can easily understand and display in a meaningful manner to the user.

Working of REST

The servers, when requested for a resource, such as text, audio, video, or any form of data, create a response object of the resource, requested by the client. Then transfers the representational state of the object in a standardized format over the internet.

Hence, the name REpresentational State Transfer. Any complex operation that has to be performed on the resource will be broken down to into individual modules. And then each of these modules are executed on different layers in a logical order as previously explained under the layered system design principle. This approach thus provides greater benefits, such as flexibility and scalability.

Methods that are Commonly used in a REST-based Architecture

In HTTP there are five methods that are commonly used in a REST-based Architecture i.e., POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and delete (or CRUD) operations respectively.

• GET: The HTTP GET method is used to read (or retrieve) a representation of a resource. In the safe path, GET returns a representation in XML or JSON and an HTTP response code of 200 (OK). In an error case, it most often returns a 404 (NOT FOUND) or 400 (BAD REQUEST).
• POST: The POST verb is most often utilized to create new resources. In particular, it’s used to create subordinate resources. That is, subordinate to some other (e.g. parent) resource. On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.
• PUT: It is used for updating the capabilities. However, PUT can also be used to create a resource in the case where the resource ID is chosen by the client instead of by the server. In other words, if the PUT is to a URI that contains the value of a non-existent resource ID. On successful update, return 200 (or 204 if not returning any content in the body) from a PUT. If using PUT for create, return HTTP status 201 on successful creation. PUT is not safe operation but it’s idempotent.
• PATCH: It is used to modify capabilities. The PATCH request only needs to contain the changes to the resource, not the complete resource. This resembles PUT, but the body contains a set of instructions describing how a resource currently residing on the server should be modified to produce a new version. This means that the PATCH body should not just be a modified part of the resource, but in some kind of patch language like JSON Patch or XML Patch. PATCH is neither safe nor idempotent.
• DELETE: It is used to delete a resource identified by a URI. On successful deletion, return HTTP status 200 (OK) along with a response body.

Idempotence

An idempotent HTTP method is a HTTP method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself.

Example:

Request and Response

Now we will see how request and response work for different HTTP methods. Let’s assume we have an API for all student's data.

GET: Request for all Students.

POST: Request for Posting/Creating/Inserting Data

PUT or PATCH: Request for Updating Data at id=1

DELETE: Request for Deleting Data of id=1