A Guide to Understanding Representational State Transfer (REST) Constraints
REST is an architectural style, a term coined by Roy Fielding in his doctoral dissertation in 2000. A REST API operates on a client-server model, where the client (such as a web browser or mobile app) sends requests to the server, which processes those requests and returns appropriate responses. An API is a messenger that enables communication between two computers. We encounter this process daily. For instance, Airbnb uses the Google Maps API to display the locations of holiday rental properties. The most widely used API standard for mobile and web apps to interact with servers is REST. REST establishes a set of constraints. While custom API implementations are perfectly fine, they cannot be considered truly RESTful unless they comply with all the required constraints. Let's go through each of the REST constraints.
REST Constraints
Uniform Interface
This constraint specifies that the API and its consumers share a single, unified technical interface. The goal is to ensure consistency across different APIs. It involves a combination of resource Uniform Resource Identifiers (indicating the location of the resource), HTTP methods (defining how to interact with the resource), and representations (such as XML, JSON, etc). This constraint has four sub constraints.
Identification of resources
A REST API is made up of resources and Uniform Resource Identifiers (URIs). Resources represent the entities within a system. Each resource is assigned a unique identifier called a URI. The URI serves as the address that clients use to access the resource.
Manipulation of resources through representations
In REST, resources are not manipulated directly; instead, they are interacted with through their representations. The client works with these representations (typically in JSON format) to interact with and modify the underlying resources.
When a client retrieves a resource's representation from the server, the response must contain enough information for the client to modify or delete that resource, provided it has the necessary permissions.
Self-descriptive message
When a consumer requests data from an API, a request message is sent, and the data returned to the consumer is a response message. This constraint ensures that each message contains all the necessary information for processing. In other words, the recipient (whether client or server) should be able to understand and process the message without needing any additional context.
HATEOAS (Hypermedia as the Engine of Application State)
The HATEOAS constraint means that a RESTful API includes the necessary links in the response to guide the client. With this approach, the client can use the links returned in the response to determine what actions are possible on the API, without needing prior knowledge of how the API contract is structured.
For more information, check out this blog on HATEOAS.
Client Server
A client (the consumer of the API) should not be concerned with how the API stores data or processes requests, nor does it need to know how the API is developed. Similarly, the server should not be concerned with the client’s user interface or its implementation details. This separation allows both the client and the server to evolve independently of each other.
Code on Demand
This is an optional constraint, typically applied to web applications. For instance, the server can send executable code (usually JavaScript) to the client (a web application) to enhance its functionality. However, it's important to be cautious, as this can introduce security vulnerabilities.
Statelessness
A client request includes all the necessary information for the server to process it. The server treats each request as an independent operation, unrelated to previous requests—meaning each request is stateless. The server does not retain any client state information.
Layered System
A REST-based solution employs a layered architecture, where different layers serve specific purposes, such as caching, load balancing, or calling a third-party API. The client interacts only with the outermost layer and is unaware of the other layers. This design enhances scalability, flexibility, and modularity, as each layer operates independently, reducing overall system complexity.
Cache
Each time the API returns a response to the client, it must explicitly indicate whether the response can be cached. If caching is allowed, the client can use the cached data instead of making another API call, thereby improving performance. The Cache constraint is discussed in more detail in this blog post.