Lecture
REST is a software architecture style for building distributed, scalable web services. Roy advocated the use of standard HTTP methods in a way that would give a specific meaning to requests.
REST (abbreviated from English. Representational State Transfer - “transfer of the presentation state”) is an architectural style of interaction between components of a distributed application in a network. REST is a consistent set of constraints taken into account when designing a distributed hypermedia system. In certain cases (online stores, search engines, other data-based systems) this leads to increased productivity and simplified architecture. In a broad sense, components in REST interact in a manner similar to the interaction of clients and servers on the World Wide Web. REST is an alternative to RPC [1].
On the Internet, a remote procedure call can be a simple HTTP request (usually “GET” or “POST”; this request is called a “REST request” ), and the necessary data is transmitted as request parameters.
For web services based on REST (that is, not violating the restrictions imposed by it), the term “ RESTful ” is used.
Unlike SOAP-based web services (web services), there is no “official” standard for RESTful web APIs. The fact is that REST is an architectural style , while SOAP is a protocol. Although REST is not a standard in itself, most RESTful implementations use standards such as HTTP, URL, JSON, and XML.
The most important notes :
1) better use simple minimal and typical and standarts REST API path/request for
1.1 each list enpoints must have structure:
GET {base_url}/v1/categories
GET {base_url}/v1/items
with filters params, and not use any words inside paths (all,filter etc)
each end points with list can consist filters or fileds params (if consist - then need describe them)
1.2 for get one entity :
GET {base_url}/v1/item/{id}
for create
POST {base_url}/v1/item + params
for update
PUT/PATCH /{base_url}/v1/item/{id} + params
for remove
DELETE {base_url}/v1/item/{id}
2) each an answer(responce) must be typical:
2.1 if list
{
"items/or/data" : [ …. list of entities
{"id":1, name:"intellect.icu"} ,
{…}
],
"page" : 1,
"total/or/totalpage” :12
}
2.2 if once entity:
{
"id":1,
"name":"intellect.icu" ...
}
2.3 difficult list (very rarely this is used, but it is possible)
{
"items/or/data" : [ …. list of entities
{"id":1, name:"intellect.icu",
"sublist":["item1","item2"]} ,
{…}
],
"page" : 1,
"total/or/totalpage” :12
}
3. all incorrect answer (responce) from server must be typical
HTTP code 422 and body:
{
"message": "Could not to add a new item.",
"errors": {
"name_field1": ["The text message for this field."],[...],
"name": ["The name is required"]
}
}
Roy Fielding suggested using the Web not only for communication between man and machine, but also for communication between machines. REST is designed so that if used correctly, you can build an application (with API) that will work and scale for centuries .. There is no Words about API, HTTP or beautiful URLs. However, in practice, this concept is expanded on the api, url, methods.
Thus, these HTTP requests will have different meanings in REST:
There are only some types of queries above, but their entire list is: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE .
So, a single RESTful API transaction will consist of at least the following:
Let us think for a minute, what happens when we type the string somestring in the browser and click. Does the browser send the request somestring to the server? Of course not. Everything is a little more complicated. It analyzes the string, extracts the server name and port from it (as well as the name of the protocol, but this is not interesting to us now), establishes a connection to the Web server at the server: port and sends it something like the following:
GET somestring HTTP / 1.0 \ n
...other information...
\ n \ n
Here, \ n means a newline character, and \ n \ n are two required newline characters that are a marker for the end of the query (more precisely, the end of the query headers). Until we send this token, the server will not process our request.
As you can see, after the GET-line can follow other lines of information, separated by a line feed. They are usually formed by the browser. Such strings are called headers, and they can be any number of them. HTTP protocol sets the rules for the formation and interpretation of these headers. So here we begin our introduction to the HTTP protocol. As you can see, it is nothing more than a set of headers between the server and the browser, and a couple more agreements on the POST method, which we will soon consider.
Not all headers are processed by the server — some are simply sent to the running script using variable environments.
Environment variables are named parameter values that the operating system (more precisely, the parent process) passes to the running program. The program can use special functions to get the value of any set environment variable by specifying its name. This is exactly what a CGI script should do when it wants to know the meaning of a particular request header. Unfortunately, the set of headers passed to the script is limited by standards, and some headers cannot be obtained from the script in any way (the corresponding environment variable is simply not available to it). Such cases we will stipulate separately.
Below are some of the request headers with their descriptions, as well as the names of the environment variables that the server uses to pass them to the CGI script.
GET request method
Request format: GET script? HTTP / 1.0 parameters
>>> Environment Variables: REQUEST_URI; The variable QUERY_STRING stores the value and parameters, the variable REQUEST_METHOD has the keyword GET.
This header is mandatory (unless the POST method is used) and specifies the address of the requested document on the server. Parameters are also set that are sent to the script (if nothing is passed to the script, or it is a regular static page, then all the characters after the question mark and the sign itself are omitted). Instead of the HTTP / 1.0 string, another protocol may be specified — for example, HTTP / 1.1. It is his agreement that will be taken into account by the server when processing data received from the user and other headers.
The string script - parameters is set in the same format in which it appears in the URL. It would be nice to call this line somehow more realistic to take into account the possibility of the presence of command parameters in it. This name really exists and sounds like a Universal Resource Identifier ( URI ). Very often it is mixed with the concept of a URL (to the extent that this happens even in official HTTP standards documentation). By the word URL, we mean the full path to a web page along with the parameters, and the URI is the part of it, located after the host name (or IP address) and port number.
POST request method
Request format: POST script? HTTP / 1.0 parameters
>>> Environment Variable: REQUEST_URI; The variable QUERY_STRING stores the value and parameters, the variable REQUEST_METHOD contains the word POST.
The time has come to consider the POST method. Here is a practical example of the POST request method:
POST /script.cgi HTTP / 1.0 \ n
Content-length: 6 \ n
\ n
Hello!
The server will begin processing the request, without waiting for the data transfer after the end of the headers token. In other words, the script will start immediately after sending \ n \ n, and wait or not wait until the string Hello! 6 bytes long is his business. The latter means that the server does not interpret POST data in any way (just as it does not interpret certain headers), but sends them directly to the script. But how does the script know when the data ends, that is, when does it stop reading the information received from the browser? The environment variable Content-Length will help him in this, and it should be oriented towards it.
Why do I need a POST method? Mainly in order to transfer large amounts of data. For example, when uploading files via the Web or when processing large forms. In addition, the POST method is often used for aesthetic purposes: the fact is that when you use GET, as you probably have already noticed, the URL of the script becomes rather long and inelegant. The parameters passed to the script are not displayed in the browser window, the POST request leaves the URL unchanged.
The REST architecture is described by six constraints. These limitations, as applied to architecture, were originally presented by Roy Fielding in his doctoral dissertation and define the basics of RESTful style.
Six restrictions:
A single interface defines the interface between clients and servers. This simplifies and separates the architecture, which allows each part to develop independently. Four principles of a single interface:
Individual resources are defined in the request, for which the URI is used, as resource identifiers. The resources themselves are conceptually separated from the representations that are returned to the client. For example, the server does not send its database, but rather some HTML, XML or JSON, which represents some records in the database, for example, in Finnish and in UTF-8, depending on the details of the request and the implementation of the server.
When a user has an idea of a resource, including related metadata, he has enough information to modify or delete a resource on the server, if he has permission to do so.
Each message contains enough information to describe how to execute it. For example, the called parser can be described using the Internet media type (also known as MIME). Answers also clearly indicate their ability to cache.
Clients provide status via body content, query string parameters, request headers, and the requested URI (resource name). This is called hypermedia (or hypertext hyperlinks)
Along with the above description, HATEOS also means that, if necessary, references are contained in the response body (or headers) to support the URI of retrieving the object itself or the requested objects. Later, we will touch on this topic more deeply.
A single interface also means that any REST service must provide its fundamental design.
Since REST is an acronym for REpresentational State Transfer, statelessness is an important feature. Thus, this means that the necessary state for processing the request is contained in the request itself, either within the URI, the parameters of the query string, body or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of this resource. Then, after the server completes processing, the state or part of it (s) is returned back to the client through the headers, status, and response body.
Most of us who have been in this industry are accustomed to programming in a container that gives us the concept of a "Session that maintains the state of several HTTP requests. In REST, the client must include all the information for the server to execute the request, re-sending the state as needed if This state should cover multiple requests. Lack of states provides greater scalability, as the server does not need to support or communicate through the session state. In addition, the load balancer will not have to worry Talk about session and system connectivity.
So what is the difference between a state and a resource? The state or state of the application is that the server cares to execute the request to obtain the data necessary for the current session or request. A resource state, or resource, is data that defines the representation of a resource, for example, data stored in a database. Consider the state of the application as data that may vary depending on the client and the request. On the other hand, the status of resources is constant for each client who requests it.
Everyone encountered a problem with the "Back" button in their web application, when it behaves differently at one point, because what were the expected actions in a certain order? This happens when the principle of statelessness is violated. There are cases when the stateless principle is not respected, for example, three-legged OAuth, API call speed limit, etc. However, make every effort to ensure that the state of the application does not take several requests to your service.
As with the World Wide Web, the client can cache responses. Thus, responses explicitly or implicitly define themselves as cacheable or not, to prevent customers from reusing outdated or incorrect data in response to further requests. Well-designed caching partially or completely eliminates some client-server interactions, contributing to further scalability and performance.
A single interface separates clients from servers. Separation of interfaces means that, for example, clients are not connected to the storage of data that remains inside each server, so that the mobility of the client code is improved. Servers are not connected to a user interface or state, so servers can be simpler and scalable. Servers and clients can be replaced and developed independently until the interface is changed.
Typically, customers can not say - they are connected directly to the server or communicate through an intermediary. A staging server can improve system scalability by providing load balancing and providing shared cache. Layers may also be responsible for security policy.
Servers can temporarily expand or customize client functionality, passing it logic that it can execute. For example, it can be compiled Java applets or Javascript client scripts.
Fielding pointed out that applications that do not meet the given conditions cannot be called REST applications. If all the conditions are met, then, in his opinion, the application will receive the following benefits
, we allow a distributed system of any type to have such properties as: performance, extensibility, simplicity, upgradeability, comprehensibility, portability and reliability.
Note The only optional restriction for a RESTful architecture is "code on demand". If the service does not pass on any other conditions, then it definitely can not be called RESTful.
Comments
To leave a comment
Running server side scripts using PHP as an example (LAMP)
Terms: Running server side scripts using PHP as an example (LAMP)