Overview of REST. Part 1: What is REST

Hello, today we will study a very interesting, and most importantly, in-demand topic in the labor market - REST. We will break the overview of REST 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’ll look at how communication occurs between the client and 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 for Representational State Transfer . This is an architectural style of interaction between distributed system components in a computer network. Simply put, REST defines a style of interaction (data exchange) between different components of a system, each of which may be physically located in different places. This architectural style represents a consistent set of constraints that are considered when designing a distributed system. These restrictions are sometimes called REST principles. There are not many of them, only 6 pieces. We'll 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 doctoral dissertation "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 basis 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, take a look at Fielding's dissertation .

REST restrictions and principles

As stated above, REST defines how the components of a distributed system should interact with each other. In general, this happens through request-response. 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 a server . Requests and responses are most often sent via HTTP (HyperText Transfer Protocol). Typically, a server is some 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, D, etc. In this case, application A is both a server and a client. It all 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” six REST constraints:

1. Bringing the architecture to a 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 simplification of the server part improves the scalability of the system. The very distinction between “client” and “server” allows them to develop independently of each other.

2. Lack of condition

REST architecture requires the following condition to be met. Between requests, the server does not need to store information about the client's state and vice versa. All requests from the client must be structured so that the server receives all the necessary information to complete the request. In this way, both the server and the client can “understand” any message received without relying on previous messages.

3. Caching

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

4. Uniformity of the interface

The fundamental requirements of REST architecture include a unified, consistent interface. The client must always understand in what format and to which 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 is a unified format for client-server interaction, which describes what, where, in what form and how to send and is a unified interface

5. Layers

Layers refer to the hierarchical structure of networks. Sometimes the client can communicate directly with the server, and sometimes it can simply communicate with an intermediate node. The use of intermediate servers can increase scalability through load balancing and distributed caching. Let's give an example. Let's imagine a mobile application that is popular all over the world. Its integral part is loading images. Since there are millions of users, one server could not withstand such a heavy load. Dividing 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 least loaded at the moment, and will return the image to the client. If caching is correctly applied here at each level of the hierarchy, then good system scalability can be achieved.

6. Code on demand (optional restriction)

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

The benefits of REST

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

• performance (due to the use of 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 in Spring Boot