In this post on Architectural Constraints of REST API, you will learn six key architectural design constraints of REST API. Basically, the six architectural design constraints that I list here form the guidelines to develop and deploy web services that allow clients to access resources on a web server. These constraints are –
- Layered Architecture
- Code on Demand
- Uniform Interface
Let us discuss these constraints one by one.
Under this constraint, the server and clients are separate entities. it means they can be updated or even replaced independently. Moreover, the technology that clients and servers implement need not be the same. However, the implementation at both ends can be quite different. Accordingly, the server has no concern about how the client system is developed and vice versa. Basically, the client makes requests about the web resources using URIs and the server hosts the resources
In fact, the client and server follow the software engineering principle of Separation of Concerns. With this concept, there is a loose coupling between client and server. If somehow, the server is not available then the client can communicate with a backup server, and this fact is hidden from the client. However, they must adhere to the Uniform Interface constraint.
This is one of the most significant Architectural Constraints of REST API since it enables the decoupling between the client and the server. Also, these constraints describe the interface between these two entities. Basically, both clients and servers can evolve independently if they work with a uniform interface.
In particular, this constraint follows four guiding principles that we list below.
- Resource Identification in a Request
- Manipulation of Resource through Representations
- Self-Descriptive Messages
- Hypermedia As The Engine of Application State
Resource Identification in a Request
According to this principle, the Uniform Resource Identifier or URI identifies each web resource uniquely.
Manipulation of Resource through Representations
The representation or format of a resource should have enough information that allows its manipulation, such as a unique id. Basically, the resource should have appropriate representation such as proper naming conventions and a format like XL or JSON.
The messages should have enough meta-information so that they can be processed. Usually, this information includes the HTTP Response code, content-type, etc.
Hypermedia As The Engine of Application State
Basically, hypermedia is a link included in a web resource. It helps the client discovering other resources.
HTTP (HyperText Transfer Protocol) inspires the concept of statelessness. The server is not storing any client context. It is the client, who is responsible for managing the state including the session state variables. The server can restrict itself for manging resources only, while the client implements methods for maintaining the application state.
The benefit of the server being stateless is that it enables load balancing by deploying additional servers. In particular, if the clients maintain the session state, replacing the server is not visible to the client. However, it requires additional bandwidth for transferring the state data along with the requests.
This architectural design guideline encourages the use of caching wherever possible. Basically, caching is a technique that allows storing a web resource such as a web page temporarily at either a client location or at a server location. when a request arises of a resource, then its cached version is served if it is available rather than regenerating the resource.
As a result, the server is transferring frequently requested resources from the cache and thereby significantly increasing the performance. Basically, caheability avoids unnecessary processing for generating the response and results in less requirement of bandwidth. However, setting the optimum cache duration is also important, otherwise, it may result in serving the stale data to the client.
This constraint states that the client-server architecture should be a layered architecture. Accordingly, the client may interact with the server directly or indirectly. In fact, the layered architecture constraint allows the client to access any of the available servers which fulfill the client request. Basically, the client is not aware of the fact that it is interacting with the actual server itself or with an intermediary. Hence, in the case of an increase in traffic, load balancing becomes possible.
Code on Demand (Optional)