What is RESTful in reality?
Is your application RESTful? To answer this question, you must first understand what RESTful is. There is an opinion that giving the correct response codes to HTTP is already RESTful. Or making the right idempotent HTTP requests is generally very RESTful. We in Hexlet did a practical course on the HTTP protocol ( version differences, form submission , authentication, cookies, etc. ), and in it we try to talk about the proper use of requests, but you need to understand that RESTful is not about HTTP, it's not about Internet protocols. Modern web and interaction between the browser and the server using HTTP and URIs may be RESTful or may not.
In today's translation - a simple and clear description of RESTful, and what the system should be, so that it can be called that.
')
If you're a web developer, you've probably heard about REST. But if you are the same as me, then you usually pretend and nod politely when you are asked if you are doing everything RESTful. I use HTTP, uh, so this is RESTful, right? Recently, I finally decided to find out what this buzzword means, which sounds so peaceful (“restful” from English “soothing”, “calm”).
REST is an abbreviation of Representational State Transfer (“presentation state transfer”). This is a consistent set of architectural principles for creating a more scalable and flexible network. These principles answer a series of questions. What are the components of the system? How should they interact with each other? How to be sure that you can replace different parts of the system at any time? How can a system scale to serve billions of users?
Roy Fielding was the first to use the term REST in 2000 in his doctoral thesis “ Architectural styles and design of software network architectures ”. At the time of the publication of the thesis, the World Wide Web (Web) was already very popular. Fielding essentially stepped back and analyzed the features that made the Web more successful than competing Internet protocols. He then developed the concept of a framework for creating network communications, like a browser. So REST is a common set of principles that are not specific only to the Web. It can be applied to other types of networks, such as embedded systems. REST is not a protocol, as it does not specify implementation details.
In Fielding’s thesis, there is a group of architectural constraints that a RESTful-compliant system must satisfy. Below, I give a brief overview of each of these limitations and reason how the Web satisfies them, based on its core technologies: HTTP, HTML, and URI. (If you are not familiar with the URI, consider its “URL.” They are different, but this is not important in our discussion). Let's look at each of Fielding's restrictions.
The first limitation indicates that the network should consist of clients and servers. A server is a computer that has the required resources, and a client is a computer that needs to interact with resources stored on the server. When you dig into the Internet, your computer acts as a client and sends HTTP requests to the server in order to access and work with the information. A RESTful system must perform operations in the client-server model, even if the component periodically behaves either as a client or as a server.
An alternative to a client-server architecture built without REST is event-based integration. In this model, each component continuously transmits events, intercepting corresponding events from other components. There is no one-to-one interaction, only transmission and interception. REST requires one-to-one interaction, so an event-based architecture will not satisfy RESTful requirements.
The concept of "no state" does not mean that the servers and clients do not have it, they simply do not need to monitor the state of each other. When a client does not interact with the server, the server has no idea of ​​its existence. The server also does not keep records of past requests. Each request is considered as independent.
The constraint ensures that there is a common language between servers and clients, which allows each part to be replaceable or changeable, without compromising the integrity of the system. This is achieved through 4 sub-limitations: resource identification, resource manipulation through representations, “self-contained” messages, and hypermedia.
The first subunit of the “unified interface” affects how resources are identified. In the terminology of REST, anything can be a resource — an HTML document, an image, information about a specific user, etc. Each resource must be uniquely identified by a permanent identifier. "Permanent" means that the identifier does not change during the exchange of data, and even when the state of the resource changes. If a resource is assigned a different identifier, the server must inform the client that the request was unsuccessful and provide a link to the new address.
The Web uses a URI to identify resources, and HTTP uses it as a communication standard. To get the resource stored on the server, the client makes an HTTP-GET request to the URI that identifies this resource. Every time you type an address in the browser, the browser makes a GET request to this URI. If the browser receives back 200 OK and the HTML document back, then the browser renders the page in the window and you see it.
The second subunit of the “unified interface” says that the client manages resources, directing the view server, usually in the form of a JSON object containing content that he would like to add, delete or modify. In REST, the server has full control over the resources, and it is responsible for any changes. When a client wants to make changes to resources, he sends the server an idea of ​​how he sees the final resource. The server accepts the request as an offer, but it still remains under complete control.
Let's take a blog as an example. When a user creates a new blog post, his computer must tell the server to add a new post to the blog. To do this, it sends an HTTP POST request or a PUT request with the contents as a new blog entry. The server returns a response indicating that the record was created or there was a problem. In the non-REST world, a client can literally give instructions to operations, such as “add a new line” and “assign a title to a record”, instead of simply sending a view of how he sees the final resource.
3rd interface restriction: self-contained messages
self-contained messages are another limitation that guarantees the unification of the interface for clients and servers. Only a self-contained message contains all the information that is necessary for the recipient to understand it. There should be no additional information in a separate documentation or other message.
To understand how this relates to WEB, let's analyze a set of HTTP requests and responses.
When a user types www.example.com in the address bar of a web browser, the browser sends the corresponding HTTP request:
This is a self-contained message, because it sends the HTTP method and the protocol (HTTP 1.1) to the server.
The server can send a response like this:
This is a self-contained message because it tells the client how to interpret the message text (thanks to Content-type = text / html). The client has everything that is needed in this one message to handle it accordingly.
Imagine an alternative method of communication, when the server sends a binary code in one answer, and then a separate message that tells the client how to interpret the binary code, whether it is an image or a code fragment. If the two answers are somehow delivered in the wrong order, or a third message is inserted between them, the client will become confused and will not be able to correctly interpret these messages.
The last interface limit is the hypermedia limit. Hypermedia is a pretentious concept for data that contains information about what the customer needs to do next, in other words, what other requests he can make. In REST, servers should only send hypermedia to clients.
HTML is one type of hypermedia. To better understand this, let's look again at the server response above.
When the system has identifiers for each resource, controls them through the direction of views from the client to the server, contains self-contained messages and is composed of hypermedia, then they say that it has a unified interface . This is probably the most important attribute of the RESTful system, as it allows customers to adapt to change. The server can change the base implementation without terminating all the clients that interacted with it, because each interaction is self-sufficient: the identifiers do not change when the base states change or the implementation changes, and hypermedia gives clients instructions for state-to-state transitions that they can later execute. The server does not need to remember anything about the client or do something special to satisfy it, and vice versa.
There are three more Fielding restrictions that we will look at briefly here.
Caching : server responses should be marked cached or non-cached. Caching occurs when a client saves responses received earlier from the server. When this data is needed again, caching can save you from a complete pass through the network. The ability to cache exists thanks to self-contained messages. The client does not need to worry that only a part of the necessary information is accidentally cached, and other parts are lost.
The layer system assumes the presence of more components than the client and server. The system may have more than one layer. However, each component is limited by the ability to see only the adjacent layer and interact only with it. A proxy is an optional component; it forwards HTTP requests to servers or other proxies. Proxy servers can be useful for load balancing and security checks. The proxy acts as a server for the initial client that sends the request, and then as the client when it forwards the request. The gateway is another additional component, it translates the HTTP request into another protocol, distributes this request, and then translates the response received back into HTTP. The client can handle the gateway as a normal server. An example gateway is a system that downloads files from an FTP server.
On-demand code is the only optional restriction that implies that the server sends the executable code to the client. This is what happens in the HTML tag.
* * *
In general, a RESTful system is any network that meets Fielding's constraints. A RESTful system must be flexible enough for different usage scenarios, scalable to accommodate a large number of users and components, and adaptable over time. We examined how the Web meets the requirements of RESTful when it comes to human-browser interaction. Developing Web interfaces based on a RESTful architecture for intercomputer interactions is a much more complex topic (for more information, see the resources listed below). Remember that REST is a theoretical design and the Web that exists today still sometimes falls short of theory.
Next time you will not need to pretend that you know what RESTful really means.
Translation: Natalia Bass
In today's translation - a simple and clear description of RESTful, and what the system should be, so that it can be called that.
')
If you're a web developer, you've probably heard about REST. But if you are the same as me, then you usually pretend and nod politely when you are asked if you are doing everything RESTful. I use HTTP, uh, so this is RESTful, right? Recently, I finally decided to find out what this buzzword means, which sounds so peaceful (“restful” from English “soothing”, “calm”).
What is REST?
REST is an abbreviation of Representational State Transfer (“presentation state transfer”). This is a consistent set of architectural principles for creating a more scalable and flexible network. These principles answer a series of questions. What are the components of the system? How should they interact with each other? How to be sure that you can replace different parts of the system at any time? How can a system scale to serve billions of users?
Roy Fielding was the first to use the term REST in 2000 in his doctoral thesis “ Architectural styles and design of software network architectures ”. At the time of the publication of the thesis, the World Wide Web (Web) was already very popular. Fielding essentially stepped back and analyzed the features that made the Web more successful than competing Internet protocols. He then developed the concept of a framework for creating network communications, like a browser. So REST is a common set of principles that are not specific only to the Web. It can be applied to other types of networks, such as embedded systems. REST is not a protocol, as it does not specify implementation details.
Fielding restrictions
In Fielding’s thesis, there is a group of architectural constraints that a RESTful-compliant system must satisfy. Below, I give a brief overview of each of these limitations and reason how the Web satisfies them, based on its core technologies: HTTP, HTML, and URI. (If you are not familiar with the URI, consider its “URL.” They are different, but this is not important in our discussion). Let's look at each of Fielding's restrictions.
Client server
The first limitation indicates that the network should consist of clients and servers. A server is a computer that has the required resources, and a client is a computer that needs to interact with resources stored on the server. When you dig into the Internet, your computer acts as a client and sends HTTP requests to the server in order to access and work with the information. A RESTful system must perform operations in the client-server model, even if the component periodically behaves either as a client or as a server.
An alternative to a client-server architecture built without REST is event-based integration. In this model, each component continuously transmits events, intercepting corresponding events from other components. There is no one-to-one interaction, only transmission and interception. REST requires one-to-one interaction, so an event-based architecture will not satisfy RESTful requirements.
Lack of condition
The concept of "no state" does not mean that the servers and clients do not have it, they simply do not need to monitor the state of each other. When a client does not interact with the server, the server has no idea of ​​its existence. The server also does not keep records of past requests. Each request is considered as independent.
Interface uniformity
The constraint ensures that there is a common language between servers and clients, which allows each part to be replaceable or changeable, without compromising the integrity of the system. This is achieved through 4 sub-limitations: resource identification, resource manipulation through representations, “self-contained” messages, and hypermedia.
1st Interface Restriction: Resource Definition
The first subunit of the “unified interface” affects how resources are identified. In the terminology of REST, anything can be a resource — an HTML document, an image, information about a specific user, etc. Each resource must be uniquely identified by a permanent identifier. "Permanent" means that the identifier does not change during the exchange of data, and even when the state of the resource changes. If a resource is assigned a different identifier, the server must inform the client that the request was unsuccessful and provide a link to the new address.
The Web uses a URI to identify resources, and HTTP uses it as a communication standard. To get the resource stored on the server, the client makes an HTTP-GET request to the URI that identifies this resource. Every time you type an address in the browser, the browser makes a GET request to this URI. If the browser receives back 200 OK and the HTML document back, then the browser renders the page in the window and you see it.
2nd Interface Restriction: Resource Management through Views
The second subunit of the “unified interface” says that the client manages resources, directing the view server, usually in the form of a JSON object containing content that he would like to add, delete or modify. In REST, the server has full control over the resources, and it is responsible for any changes. When a client wants to make changes to resources, he sends the server an idea of ​​how he sees the final resource. The server accepts the request as an offer, but it still remains under complete control.
Let's take a blog as an example. When a user creates a new blog post, his computer must tell the server to add a new post to the blog. To do this, it sends an HTTP POST request or a PUT request with the contents as a new blog entry. The server returns a response indicating that the record was created or there was a problem. In the non-REST world, a client can literally give instructions to operations, such as “add a new line” and “assign a title to a record”, instead of simply sending a view of how he sees the final resource.
3rd interface restriction: self-contained messages
self-contained messages are another limitation that guarantees the unification of the interface for clients and servers. Only a self-contained message contains all the information that is necessary for the recipient to understand it. There should be no additional information in a separate documentation or other message.
To understand how this relates to WEB, let's analyze a set of HTTP requests and responses.
When a user types www.example.com in the address bar of a web browser, the browser sends the corresponding HTTP request:
GET / HTTP/1.1
Host: www.example.com
This is a self-contained message, because it sends the HTTP method and the protocol (HTTP 1.1) to the server.
The server can send a response like this:
HTTP / 1.1 200 OK
Content-Type: text/html
<!DOCTYPE html>
Home Page
Hello World!
Check out the Recurse Center!
This is a self-contained message because it tells the client how to interpret the message text (thanks to Content-type = text / html). The client has everything that is needed in this one message to handle it accordingly.
Imagine an alternative method of communication, when the server sends a binary code in one answer, and then a separate message that tells the client how to interpret the binary code, whether it is an image or a code fragment. If the two answers are somehow delivered in the wrong order, or a third message is inserted between them, the client will become confused and will not be able to correctly interpret these messages.
4th interface restriction: hypermedia
The last interface limit is the hypermedia limit. Hypermedia is a pretentious concept for data that contains information about what the customer needs to do next, in other words, what other requests he can make. In REST, servers should only send hypermedia to clients.
HTML is one type of hypermedia. To better understand this, let's look again at the server response above.
<a href= “http://www.recurse.com"> Check out the Recurse Center! </a>informs the client that he must make a GET request to www.recurse.com if the user clicks on the link.
<img src = "awesome-pic.jpg">Tells the client to immediately make a GET request to www.example.com/awesome-pic.jpg to display the image for the user.
When the system has identifiers for each resource, controls them through the direction of views from the client to the server, contains self-contained messages and is composed of hypermedia, then they say that it has a unified interface . This is probably the most important attribute of the RESTful system, as it allows customers to adapt to change. The server can change the base implementation without terminating all the clients that interacted with it, because each interaction is self-sufficient: the identifiers do not change when the base states change or the implementation changes, and hypermedia gives clients instructions for state-to-state transitions that they can later execute. The server does not need to remember anything about the client or do something special to satisfy it, and vice versa.
Fielding's other limitations: caching, layer system, and on-demand code.
There are three more Fielding restrictions that we will look at briefly here.
Caching : server responses should be marked cached or non-cached. Caching occurs when a client saves responses received earlier from the server. When this data is needed again, caching can save you from a complete pass through the network. The ability to cache exists thanks to self-contained messages. The client does not need to worry that only a part of the necessary information is accidentally cached, and other parts are lost.
The layer system assumes the presence of more components than the client and server. The system may have more than one layer. However, each component is limited by the ability to see only the adjacent layer and interact only with it. A proxy is an optional component; it forwards HTTP requests to servers or other proxies. Proxy servers can be useful for load balancing and security checks. The proxy acts as a server for the initial client that sends the request, and then as the client when it forwards the request. The gateway is another additional component, it translates the HTTP request into another protocol, distributes this request, and then translates the response received back into HTTP. The client can handle the gateway as a normal server. An example gateway is a system that downloads files from an FTP server.
On-demand code is the only optional restriction that implies that the server sends the executable code to the client. This is what happens in the HTML tag.
<script>. When the HTML document is loaded, the browser automatically selects on the JavaScript server and executes it locally.
* * *
In general, a RESTful system is any network that meets Fielding's constraints. A RESTful system must be flexible enough for different usage scenarios, scalable to accommodate a large number of users and components, and adaptable over time. We examined how the Web meets the requirements of RESTful when it comes to human-browser interaction. Developing Web interfaces based on a RESTful architecture for intercomputer interactions is a much more complex topic (for more information, see the resources listed below). Remember that REST is a theoretical design and the Web that exists today still sometimes falls short of theory.
Next time you will not need to pretend that you know what RESTful really means.
To read
Translation: Natalia Bass
Source: https://habr.com/ru/post/274675/
All Articles