REST API Introduction

The first module ended with you creating an HTTP request, sending it, and getting a response.

We will do this many more times in the future. We will send requests to third-party servers. We will make applications that themselves accept such requests and return a response. We will create complex logic for processing requests.

Therefore, it would be good to thoroughly study everything related to these requests, to analyze them in detail. So that you can not just copy the request somewhere and repeat it, but really figure out how it all works.

This is what we will do in the second module. Let’s go!

General information

Let's start with general information.

If you did your homework in the first module and studied the documentation, you should have noticed the acronym API. Actually, it is the API documentation that is the first thing developers should study if they want to understand the interaction with some service or application on the network.

API

API - Application Programming Interface. This is a description of the ways in which the client and server can communicate with each other. We open the API documentation and learn from there how to get the necessary data from the server.

We always want this interaction to be simple and understandable. This simplifies the task for both developers (no need to reinvent the wheel when designing a new service) and users (a service is much easier to learn if it works on the same principle as previously familiar services). And here it is worth remembering a new term - REST.

REST

REST - acronym for Representational State Transfer. It may not sound very clear, but simply put, REST is a style of interaction (exchange of information) between a client and a server.

This is not some rigid set of rules and requirements. REST does not force the use of any particular programming language, nor does it bind hands with strict guidelines. REST is called an architectural style and it defines 6 principles that a system architecture must comply with.

Accordingly, an API developed taking into account the principles of REST is called a REST API, and the applications themselves are called RESTful

We will be creating just such RESTful applications, so it is worth discussing the principles that they will comply with right away.

RESTful principles

Client-Server Model. The principle defines the separation of the client and the server, the differentiation of their needs. The client does not have to worry about how the data is stored, the main thing is that it be issued upon request. In turn, the server does not care what the client will do with this data, how to further process and display it. This allows them to develop independently of each other, and improves the scalability of the system.

Statelessness. This principle means that the server should not "think out" the response based on previous experience with this client. Any request is made in such a way that it contains all the necessary information for its processing, regardless of previous requests.

Caching. To minimize the transmitted data, there is a caching mechanism. For example, if a logo is displayed on some page, then it makes no sense to request it from the server every time. It does not change so often, it will be enough to get it once and save it on the client's computer, in the cache. But if we need to get information about the current speed of the car, then the cache will not help in any way. This principle determines that the data transmitted by the server should be designated as cacheable or not.

Uniform interface. The principle defines a single format of client-server interaction. The structure of all requests must be the same. Data must be sent in the same form, regardless of who requests it.

Layered System. The client and server do not necessarily communicate directly. Data transmission can go through several intermediate nodes. In this case, the system is designed so that neither the client nor the server knows whether they are interacting with the final application or an intermediate node. This allows you to balance the load on the servers, increase scalability.

Code on demand (optional). The only principle that is not mandatory. According to it, the client can expand its functionality by downloading executable code from the server (for example, scripts). In this case, the code should be executed only on demand.