Blog

Follow our blog and get to know about the latest updates in the fields of technology like Python, Machine Learning, Data structures, Data Science, Digital Marketing etc.

How REST API works

15.06.2021

To obtain data on the Internet, we have used a variety of applications and web pages. However, have you ever considered where this data comes from? We get the data from the servers, after all. So, in this article on How REST API works, we'll look at how a client communicates with servers to get the information they need.


Introduction to REST API

REST APIs also called RESTful APIs in which REST refers to REpresentational State Transfer  which is an architectural style that defines a set of constraints to be used for creating more than two web services. REST API is a way of accessing web services simply and flexibly without having any processing. It is a set of definitions and protocols for developing and integrating application software. It’s used to retrieve or provide information from web services. All communication is done via REST API working only with HTTP requests.


REST design beliefs

REST APIs can be developed using any programming language and support a large variety of data formats. The only condition is that codes should be aligned to the following REST APIs which have six architectural constraints:

1) Uniform interface - Any REST service must have a standard interface check since it makes it easier to use and decouples the architecture. This allows each component to evolve on its own. It is recommended that there should be a consistent  way of interaction with a given server irrespective of device or type of application. The resources should not be too large, but they should contain all of the information that the client may require.

Four guidelines principle of Uniform Interface are given below:

  • Resource-Based

  • Self-descriptive Messages

  • Manipulation of Resources Through Representations

  • HATEOAS (Hypermedia as the Engine of Application State)

2) Client-server - The REST APIs should have a client-server architecture, where client and server applications must be independent of each other. A client doesn’t need to understand any business logic and the server doesn’t need to understand anything about GUI. 

3) Stateless - In REST APIs, the client must consolidate all the information for the server to perform the request whether as a portion of query parameters, headers, or URI. Stateless when the computer or program follows the status of interaction. The important state to manage the request is included within the request itself and the server would not store anything associated with the session.

4) Cacheable - In REST APIs, being cacheable leads to improvement and performance for the client. Resources should be cacheable on the client or server side whenever possible. Server responses must also include information on whether or not caching is permitted for the delivered resource. This makes better scalability for a server because the load has been reduced. This cacheable machine concept helps to eliminate interactions that hinder performance.

5) Layered system - A multi-layered application architecture is required. Each layer knows nothing about any other layer except the immediate layer, and there may be many intermediate servers between the client and the end server. Basically, as the name states, servers may develop system availability by enabling load-balancing(LB), and by providing shared caches for communicating with each layer to have functions performed to its specifications.

6) Code on demand - It is an optional architectural constraint. According to this, servers can also give executable code to the client. it permits you to execute a real REST API and a server can improve the ability of a client on runtime.


Working on the API

A request is sent from client to server in the form of a web URL as HTTP methods. Following that, a response has come back from the server in the form of a resource which can be anything like HTML, XML, Image, or JSON. But right now JSON is the most common format being used in Web Services.

Idempotent Methods

The term idempotent refers to an operation that produces the same outcomes whether it is performed once or several times. In plain terms, it makes no difference if the procedure is called once or ten times. The outcome should be the same. Again, this is only applicable to the outcome, not the resource itself.

In terms of HTTP- GET, HEAD, PUT and DELETE are declared idempotent methods.


Following are few methods for interaction between client and server:

1) HTTP GET

Use GET requests to retrieve resource representation/information only. As GET requests do not alter the state of the resource, it is a safe and idempotent method.

when the user requests the HTTP GET API, 

- If the resource is originating on the server, then it must revert HTTP response code 200 (OK). 

- If in case the resource is NOT available on the server then it must return HTTP response code 404 (NOT FOUND). 

- If it is determined that the GET request itself is not correctly formed in the URL then the server will return HTTP response code 400 (BAD REQUEST).


2) HTTP POST

POST APIs are useful for creating new subordinate resources. e.g., a row is subordinate to a database table.  These are referred to as POST, and they are neither safe nor idempotent. Unless the response includes the appropriate Cache-Control or Expires header fields, this method's responses are not cacheable.

When the user requests the HTTP POST API,

- On successful request formed to the server, return HTTP status 201, 

- Returning a Location header with a link to the newly-created resource with the 201 HTTP status.


3) HTTP PUT

PUT APIs are primarily used to update a previously created resource (if the resource does not exist, then the API may decide to create a new resource or not). Although PUT is not a safe operation, it is idempotent. If the request is cached and the Request-URI identifies one or more currently cached entities, those entries should be considered stale. This method's responses are not cacheable.

If a user requests the HTTP PUT API to a URI,

- When an update is successful, return 200 (or 204 if no content is returned in the body.) 

- Return HTTP status 201 on successful creation if using PUT.


4) HTTP DELETE

DELETE APIs are used to remove resources from a system (identified by the Request-URI). The DELETE command is idempotent. If the request crosses a cache and the Request-URI identifies one or more currently cached objects, those entries should be considered stale. This method's responses are not cacheable.

- A successful DELETE API request should deliver HTTP response code 200 (OK) if the response includes an entity describing the status

- 202 (Accepted) if the action was queued, or 204 (No Content) If the action was carried out but no entity was included in the response.


5) HTTP PATCH

HTTP PATCH requests are to make the partial update on a resource. PUT requests also modify a resource entity, so to be clear – the PATCH method is the correct choice for partially updating a current resource, and PUT should only be used if you're completely replacing a resource. The PATCH body, rather than just a modified section of the resource, should be written in a patch language such as JSON Patch or XML Patch. PATCH is neither safe nor idempotent.


This brings us to the end of this article on “HOW REST API WORKS.” Do you have a question for us? Please let us know in the comments section, and we will respond as soon as possible.