REST overview. Part 1: What is REST

Hello, today we will study with you a very interesting, and most importantly, a topic in demand in the labor market - REST. We will break the REST overview into three parts:

1. In the first part, we will touch on the history of REST and describe the principles on which REST is based.

2. In the second, we will consider how communication takes place between the client and the server via the HTTP protocol.

3. In the third, we will write a small RESTful application, which we will test using the Postman program.

The article is intended for a reader 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 many things in the IT world, is an acronym, short for Representational State Transfer - presentation state transfer. It is an architectural style of interaction between the components of a distributed system in a computer network. Simply put, REST defines the style of interaction (data exchange) 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 that are taken into account when designing a distributed system. These restrictions are sometimes referred to as REST principles. There are not many of them, only 6 pieces. We will talk about them a little later.

History of REST

The term REST was coined by Roy Fielding, one of the creators of the HTTP protocol, in his PhD thesis "Architectural Styles and the Design of Network-based Software Architectures" in 2000. We can say that the term REST is still young, although its concept lies at the very foundation of the World Wide Web. We will not dive deep into the history of the origin of this term. If you want to dive into the original sources, check out Fielding's dissertation .

REST restrictions and principles

As mentioned above, REST defines how the components of a distributed system should interact with each other. In general, this happens through requests and responses. The component that sends the request is called the client ; the component that processes the request and sends a response to the client is called the server. Requests and responses are most often sent over HTTP (HyperText Transfer Protocol). As a rule, the server is a kind of web application. The client can be not just anything, but quite a lot. For example, a mobile application that requests data from the server. Or a browser that sends requests from a web page to a server to download data. Application A can request data from application B. Then A is a client in relation to B, and B is a server in relation to A. At the same time, A can process requests from C, D, E, etc. In this case, application A is both a server and a client. Everything depends on the context. One thing is clear: the component that sends the request is the client. The component that receives, processes and responds to the request is the server. However, not every system whose components communicate via request-response is a REST (or RESTful) system. For a system to be considered RESTful, it must “fit” into six REST constraints:

1. Bringing the architecture to the client-server model

The basis of this limitation is the differentiation of needs. It is necessary to separate the needs of the client interface from the needs of the server that stores the data. This limitation increases the portability of the client code to other platforms, and the simplification of the server side improves the scalability of the system. The very distinction between “client” and “server” allows them to develop independently of each other.

2. Lack of state

The REST architecture requires the following condition to be met. Between requests, the server does not need to store information about the state of the client and vice versa. All requests from the client must be crafted in such a way that the server receives 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. Caching

Clients can cache server responses. Those, in turn, must be explicitly or implicitly marked as cacheable or non-cached, so that clients do not receive stale or incorrect data in response to subsequent requests. Proper use of caching helps to completely or partially eliminate some client-server interactions, further increasing the performance and extensibility of the system.

4. Interface uniformity

The fundamental requirements of the REST architecture include a unified, uniform interface. The client must always understand in what format and to what addresses it needs to send a request, and the server, in turn, must also understand in what format it should respond to client requests. This single format of client-server interaction, which describes what, where, in what form and how to send, is a unified interface

5. Layers

Layers refers to the hierarchical structure of networks. Sometimes the client can communicate directly with the server, and sometimes it can just communicate with an intermediate host. The use of intermediate servers can increase scalability through load balancing and distributed caching. Let's take an example. Imagine some mobile application that is popular all over the world. Its integral part is the loading of pictures. Since there are millions of users, one server could not withstand such a large load. Delimiting the system into layers will solve this problem. The client will request an image from the intermediate node, the intermediate node will request the image from the server that is the least loaded at the moment, and return the image to the client. If caching is correctly applied here at each level of the hierarchy,

6. Code on demand (optional limitation)

This limitation implies that the client can extend its functionality by downloading code from the server in the form of applets or scripts.

Benefits of REST

Applications that comply with all of the above restrictions have the following advantages: reliability (no need to save information about the state of the client, which can be lost);

• performance (due to the use of the cache);
• scalability;
• transparency of the interaction system;
• simplicity of interfaces;
• portability of components;
• ease of making changes;
• the ability to evolve, adapting to new requirements.

Part 2: Communication between Client and Server Part 3: Creating a RESTful Service with Spring Boot