Hi! Today we will learn about a topic that is very interesting and, most importantly, in high demand in the labor market: REST.
We will divide our overview of REST into three parts:
In the first part, we will cover the history of REST and describe the principles on which REST is based.
In the second, we will consider how communication between a client and server occurs via the HTTP protocol.
In the third, we will write a small RESTful application that we will test using a program called "Postman".
The article is intended for readers familiar with the following terms:
HTTP
URL and URI
JSON and (to a lesser extent) XML
Dependency injection
Part 1. What is REST?
REST, like so much in the IT world, is an acronym. It is derived from "REpresentational State Transfer". This is an architectural style for interaction between components of a distributed system in a computer network. Simply put, REST determines the style for interaction (exchanging data) between different components of the system, each of which can be physically located in different places. This architectural style is a consistent set of constraints adhered to when designing a distributed system. These constraints are sometimes called the guiding principles of REST. There are not many, only 6. We will talk about them a little later.
Applications built with REST principles in mind, i.e. those that do not violate the REST constraints, are called "RESTful".
History of REST
The term REST was introduced by Roy Fielding, one of the creators of the HTTP protocol, in his Ph.D. thesis entitled "Architectural Styles and the Design of Network-based Software Architectures" in 2000. Though the term REST can still be called young, the concept it represents lies at the very core of the World Wide Web.
We won't dive deep into the history of the term. If you want to dive into the primary sources, take a look at Fielding's dissertation.
REST constraints and principles
As stated above, REST defines how the components of a distributed system should interact with one another. In general, this happens through a request-response process. The component that sends the request is called the client, and the component that processes the request and sends a response to the client is called the server. Requests and responses are most often sent via the HTTP protocol. HTTP stands for HyperText Transfer Protocol.
Typically, a server is some web application. The client can be almost anything. For example, a mobile app that requests data from a server. Or a browser that sends requests from a web page to a server in order to download data.
Application A may request data from Application B. In this case, A is a client with respect to B, and B is a server with respect to A. At the same time, A could process requests from B, C, D, etc. In this case, application A is both a server and a client. Everything depends on the context.
One thing is certain: the component that sends the request is the client. The component that receives, processes and responds to a request is the server.
However, not every system whose components communicate through a request-response process is a RESTful system. For a system to be considered RESTful, it must comply with the six REST constraints:
1. Client-server architecture
This constraint is about the separation of concerns. It is necessary to separate the requirements of the client interface from the requirements of the server that stores the data. This constraint makes the client code more portable to other platforms, and simplifying the server side improves the system's scalability. Making a distinction between the "client” and the "server" allows them to be developed independently of one another.
2. Stateless
A RESTful architecture requires the following conditions to be met. In the period between requests, the server must not store information about the client's state and vice versa. All requests from the client must be composed in a way that gives the server all the necessary information to complete the request. Thus, both the server and the client can "understand" any received message, without relying on previous messages.
3. Cacheable
Clients can cache server responses. These, in turn, must explicitly or implicitly be designated as cached or non-cached, so that clients do not receive outdated or incorrect data in response to subsequent requests.
Correct caching helps to completely or partially eliminate some client-server interactions, further increasing system performance and scalability.
4. Uniform interface
The fundamental requirements of a RESTful architecture include a unified, uniform interface. The client must always understand the format and addresses it needs to use when sending a request, and the server, in turn, must also understand the format it should use when responding to client requests. This consistent client-server interaction that describes what, where, in what form, and how to send data is a unified interface.
5. Layers
By layers, we mean the hierarchical structure of the network. Sometimes a client can communicate directly with the server, and sometimes it just communicates with an intermediate node. The use of intermediate servers can increase scalability thanks to load balancing and distributed caching.
Let's provide an example.
Imagine a mobile app that is popular all over the world. An integral part of the app involves loading pictures. Its users number in the millions, so a single server cannot handle such a heavy load.
Separating the system into layers will solve this problem. If the client requests a picture from an intermediate node, then the intermediate node requests the picture from the server that is least loaded at the moment and returns the picture to the client. If caching is applied correctly at each level of the hierarchy, then good system scalability can be achieved.
6. Code on demand (optional)
This constraint implies that the client can expand its functionality by downloading code from the server in the form of applets or scripts.
Advantages of a RESTful architecture
Applications that comply with all the aforementioned constraints have the following advantages: reliability (no need to save the client's state, which might be lost)
We will divide our overview of REST into three parts:
