5 Rules of REST Architecture
Yazının Türkçe versiyonuna bu link ile ulaşabilirsiniz.
What is REST?
REST is short for “REpresentational State Transfer”. It is an architectural approach for web services. Services developed in accordance with REST architecture are called Restful Web Services.
Important Keywords in REST Architecture
Resource
Resources are abstract structures that are formed by grouping the information in the domain in such a way that it creates a meaning. For example; the user resource is formed by grouping information such as name, surname and date of birth under the same roof that is called ‘user’. Another example may be that data such as buyer, products and price are being brought together and grouped to form the source of the order.
Server
It is the component responsible for grouping the data. In addition, actions to be carried out during status transitions and actions that are related to changes that can be made on data fall under the responsibility of service provider.
Client
Although the user keyword reminds us of human, programs such as background services are also considered as users. In order to be qualified as a client, it is sufficient for the service provider to perform operations on the resource it serves.
What are the Rules and Benefits of REST Architecture?
1 — Client Server Architecture
There are two important participants in web service structures where REST architecture is used; server and client. One of the rules of REST architecture is that the server and the client are independent from each other. In other words, these two components should be able to be developed independently.
With this rule, we can use a single service provider for many clients because our service providers are developed in a way that they do not operate per client. In addition, even if we change the programming language or data storage platform used on the server side, we will not need to make any changes on the client side because this information will already be abstracted against the client. Similarly, we can make changes on the client side and start using the new version of the service, and developer will not need to make any changes on the server side.
2 — Stateless
In web services where REST architecture is used, all the information required to execute the requests should come with the request. In order to process a request, data previously stored on the machine should not be needed.
Via this rule, our applications can be horizontally scalable. Since each request has all the data required to execute the process, the request can be processed on any machine where the application which is developed by the service provider is installed. If we make development without complying with this rule, in order to process a request, some information must be stored on a machine beforehand. In this case, we create sessions on the machines. Let’s imagine a system of thousands of machines. All machines except one are idle. If the client’s session is opened on the busy machine, our client cannot use the idle machines and waits for service. In this case, we will not be able to use our resources efficiently.
3 — Cacheable
Cache can be described as the process of storing a copy of the data in an easily accessible environment and retrieving the data from a medium that can be accessed faster than the source of truth. When web services meet the client’s request, information about whether the data is cacheable or not should be returned. Also, a version number among cacheable data is transmitted to the client. As long as the version number of the data that the user holds is valid, this information can be used over and over again.
It is aimed to establish less communication between the client and the server through this rule. With this rule, client will use resources more efficiently and take actions in a rapid manner. Moreover, the load on the server will decrease.
4 — Layered System
According to this rule, the client side should not know whether it is communicating with an intermediate service provider or the last layer to execute the operation.
With this rule, the necessity of loosely coupling between server side and client side has been emphasized once again. The client being not aware whether it receives service from a single machine or from different machines via tools such as load-balancer is the result of compliance with this rule.
5 — Uniform Interface
This rule states that the service must be served to the client without any implementation details.
In this way, services prepared with different architectures and different implementations will be presented to the user in similar ways. This will make it easy to use for the client. Thanks to the standardized presentation, there will be a common perception among software developers. Different software developers who are looking at the same endpoint — whether developing with procedural language or an object-oriented language — will make the same meaning.
This rule has been described with 4 sub-items.
Resource identification in requests
When sending a request to the server, the resource for which the state transfer is requested must be specified in this request.
As an example, let’s imagine we want to execute an action on account resource. When we use endpoints such as [POST] http://base-url/accounts or [GET] http://base-url/accounts?name=adem, we indicate via URI that we have a request to execute an operation on the account resource.
Resource manipulation through representations
When a data belonging to the source is obtained on the client side, this data should be sufficient to make the necessary changes on the source.
We can explain this rule as follows. Let’s assume that we need to use the [PATCH] http://base-url/products/PRODUCT_ID endpoint when we want to make a change on the dataset represented as product. We need to show which product we want to process with PRODUCT_ID data. On the other hand, suppose that when we obtain the products data by executing the GET action, we cannot see a PRODUCT_ID value of the product in this data set. In this case, the data we receive from the products source is not sufficient for us to make a change on the product source. This situation shows that we do not comply with the REST architecture.
Self-descriptive messages
In order for the responses received from the server to be processed by the client, the message must have information describing itself.
Content-Type header field may be one of the examples that best explains this situation. In the value part corresponding to this header field we can see the information such as “application/json”, “text/html” et cetera. When we look at this field, we can understand what kind of parse operation will be executed for the message.
Hypermedia as the engine of application state
The client should be able to access other necessary resources through the links included in the answers client receives.
Let’s imagine we are browsing an e-commerce site. Let’s also imagine that we have requested data of category with the id value 42.
[GET] http://base-url/categories/42In the category response that we receive, there should be information about how to access products belonging to this category.
{
categoryId: 42,
categoryName: "office-supplies",
links:[
"href": "42/products",
"rel": "products",
"type" : "GET"]
}6 — Code on Demand
The server must be able to provide executable program parts to the client.
An example of this rule is that the server can provide executable code fragments such as javascript to the client.
This rule is optional for REST. For this reason, there are 5 main rules that show whether we comply with the REST architecture.
I hope it has been a useful post. You can click on this link to browse my other articles.
