Representational State Transfer (REST)

Representational State Transfer (REST)

REST is the undisputed, go-to architecture for the vast majority of today's APIs. According to nordicapis.com, over 90% of the developers are using REST APIs. In this article let's understand what is REST and why it is so popular in developing web APIs.

What is REST?

REST is a web architecture style proposed by Roy Fielding in 2000. With the advent of world wide web (WWW) in 1990, the number of people using web increased rapidly year over year and Web was on the way to suffer scalability and performance issues. This forced the software architects to design an efficient web architecture to make the web scalable, performant and flexible. Then REST architecture was proposed and it plays a crucial role in designing the scalable systems.

REST Contraints:

Roy Fielding REST architecture style defines below 6 constraints.

  1. Client-Server: REST applications must maintain a server that manages the application data and state. Server is responsible for processing the client's requests or user interactions and provides the response back to the clients.

    Both client and server must be maintained separately and they should be independent of each other as long as they both follow the same interface to communicate each other. The core principle of Separation of concerns focuses on this client-server separation so that they can independently evolve and scalable.

  2. Stateless: REST applications must be stateless. The server should not maintain any of the earlier request's data to process the current the request. The client's request should contain all the necessary information for the server to process the request. The state or session data should be maintained at the client's side.

    Stateless provides reliability and scalability of the applications as each request is independent and doesn't need to worry about the data loss and no additional time required to look for the previous requests as there is no data maintained at the server.

  3. Cacheable: REST applications mark their response data as cacheable or not. This lets clients if they want to cache the response data or not. Clients can chose to cache the response data for identical requests to improve the performance. Clients also can not chose to cache the response by reading the response header like Expires or Last-Modified etc.

     GET /index.html HTTP/1.1 200 OK
     Host: www.example.com
     Connection: Keep-Alive
     Date: Thu, 15 Sep 2022 13:22:33 GMT
     Server: Apache
     Content-Encoding: gzip
     Expires: Thu, 01 Jan 1970 00:00:00 GMT
     Last-Modified: Thu, 31 Mar 2024 13:22:18 GMT
    
  4. Uniform Interface: An application system is normally composed of several components and having uniform interface between these comopents is one of the REST's most defining characteristic. Roy Fielding states, “The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.

  5. Layered System: The components of the REST system cannot see beyond their layer and making it visible only to the adjacent layer and hiding it from the other layers. Each layer can be maintained and added with advanced functionality with out affecting other layers. This enhances the decoupling and thus increases the scalability of each component easily.

  6. Code-on-demand: This constraint enables web servers to send the executable code such as plugins, scripts etc to the clients. The clients can receive the code on demand and execute it if they need it. The clients must understand the code it receives from the web server and it is possible that not all clients uses the same technology. So such a constraint can not be made mandatory and that is why this constraint is considered as optional.

In this article, we have discussed about 6 constraints that the REST architecture style defines. Unfortunately, many sites don’t meet these requirements, yet they’re still referred as REST. This prompted Leonard Richardson to create a model for differentiating the levels of REST compliance. This is known as the Richardson Maturity Index. We will discuss about REST APIs and the levels of REST compliance in the next article.