RESTful API - Architectural Constraints

In my last article, I wrote about the basics of REST API. Like what is a RESTful API and reasons behind naming it so. If you have missed that, check it out here. I mentioned the following line in my last post:

REST is not any standard or technology rather it is an architectural style for developing API based on a standard set of principles.

So in this article, let's see what are those architectural constraints and principles that make an API RESTful.

There are 6 design principles, also known as REST Architectural constraints. These principles were described by Roy Fielding in his dissertation paper, which was published in 2000.

These following 6 architectural constraints makes any API service RESTful:

• Uniform Interface
• Client-Server
• Statelessness
• Caching
• Layered System
• Code on Demand

1. Uniform Interface

   
   Here interface refers to a contract for communication between the API provider and the consumer. The API provider and consumer here share a common technical interface, which is well-defined using HTTP methods and media types.
   This interface states that inside the system there are resources and to get the state of a resource or to manipulate it there has to be an URL that the consumer can use.
   On the server-side data is stored in the database and there is some sort of database representation. Whereas on the consumer/client-side data may be required in formats like JSON, XML, TXT, etc., which may be different from the way data is stored in the database. So, the idea here is that there must be specific guidelines for resource representation.  
   Also, there have to be some self-descriptive messages, known as metadata. This metadata helps both the producer and consumer to process the information in the request or response object. This metadata is transferred via HTTP headers. Like Content-Type which tells about the data format(JSON/XML,etc.),  HTTP status code which tells the status of the request like 200 for Success, 404 for Not Found, also Host which indicates the IP of the server.
   The last thing about this is the Hypermedia, which states that the server not only sends response data but also sends the possible actions, which the client can take on the data, whenever required. This is also referred to as HATEOAS (Hypermedia as the Engine of Application State)
   
   

2. Client-Server 

   
   The Client-Server architecture states that we have a client and a server working independently. The client connects to the server via a uniform interface. The client and server must not reside in the same process. All communication between them must happen via RPC over HTTP. This the architecture ensures that client application and the server must be able to evolve separately without any dependency on one another, as long as the uniform interface is not altered.

3. Statelessness 

   Statelessness means that the server will not store any information regarding the latest request made by the client. There will be no sessions and no histories. Every client request will be treated as a new request.
   If the end-user wants a stateful application, then the client application needs to manage the state of the application. Like, if the user wants an application where the user logs in and performs actions which are authorized to that user only, then in each request made by the client should contain all the necessary the information which is needed by the server to process the request, like authentication tokens, authorization details, etc.

4. Caching

   

    

   Caching is the ability to store copies of frequently accessed data in several places along with the request-response path.
   In terms of REST APIs, caching is storing the response of APIs in an in-memory or distributed system, so that response can be fetched from the stored system within a short amount of time. Caching can improve performance and achieve higher scalability on the server-side.
   The architectural constraint for caching states that the server should mark the responses as cacheable or non-cacheable. It can be achieved by the server using HTTP headers.
   • Cache-Control: With this header, the server defines the policy for the cache. Like who can cache the data, for how long data can be cached, etc.
   • Expires: This tells the client when the cached resource will get expired
   • Last-Modified: With this header, the server tells the client when a resource in the cache was last modified
   • ETag: This is a unique identifier associated with a resource. It can be any unique id or name
   
   

5. Layered System

   

    

   This architectural constraint states that the client-server architecture should consist of multiple layers. No one layer should be able to see past its immediate next layer. One thing not allowed is that the client is directly connected to the app server. One thing that is required here is that the client must not connect directly to an App server because if this happens then the client has to carry out request/load distribution, which is not desirable.
   The benefits of layering are that it simplifies the architecture and hides the complexity of the various layers and also, the architecture can easily change as per needs by adding or removing any layer.

6. Code on Demand (Optional)

   This is an optional constraint. This constraint states that the server can extend the client's functionality by sending executable code along with the data in response. Some examples of code on demand are Java Applets, JavaScript snippets, etc. 

All the above constraints (except point 6) must be followed to build a truly RESTful API.
These are the basic concepts that a developer should have knowledge of before indulging in advanced REST API development. Next up I will be sharing an article on hands-on development of a REST API and also deploying it to a cloud server.
So do subscribe. Also, I’d like to grow my readership, If you enjoyed this blog post, share it with a friend! Stay safe and Happy Coding!