Developers Club geek daily blog

1 year, 4 months ago
And your application — RESTful? To answer this question it is necessary to understand at first that such RESTful. There is an opinion that to give the correct codes of answers to HTTP is already RESTful. Or to do the correct idempotent HTTP requests is in general very much RESTful. We in Heksleta made a practical course under the HTTP protocol (differences of versions, sending forms, authentication, cookies and so forth), and in it we try to tell about the correct use of requests, but it is necessary to understand that RESTful it not about HTTP, it at all not about internet protocols. The modern web and interaction between the browser and the server by means of HTTP and URI can satisfy to the principles of RESTful, and can not satisfy.

In today's transfer — the simple and clear description of RESTful and what has to be system that it was possible to call it so.

What is RESTful actually

If you are engaged in web development, you most likely heard about REST. But if you same as I, then usually you pretend to be and politely nod when ask you whether all of you do RESTful. I use HTTP, eee, means - it is RESTful, so? Recently I decided to find out at last what means this fashionable word which sounds so umirotvoryayushche ("restful" with English "soothing", "quiet").

What is REST?


REST is an abbreviation from Representational State Transfer ("transfer of a status of representation"). It is the approved set of the architectural principles for creation of scalabler and flexible network. These principles answer a number of questions. What components at system? How they have to interact with each other? How to be sure that it is possible to replace different parts of system at any time? How the system can be scaled for service of billions of users?

Roy Fielding the first used the term REST in 2000 in the doctoral dissertation "Architectural styles and design of program network architectures". At the time of the publication of the thesis the World Wide Web (Web) was already very popular. Fielding, in essence, stepped back and analyzed lines which made Web more successful, than the competing internet protocols. Then it developed the concept of a framework for creation of network communication, similar to the browser. So REST is the general set of the principles characteristic not only for Web. It can be applied to other types of networks, it as the embedded systems. REST — not the protocol as it does not set implementation parts.

Fielding's restrictions


In Fielding's thesis there is a group of architectural restrictions to which the system conforming to requirements of RESTful has to satisfy. Below I give the short overview of each of these restrictions and I argue as Web satisfies with it, on the basis of its main technologies: HTTP, HTML, and URI. (If you are not familiar with URI, consider it as "URL". They differ, but in our discussion it is not important). Let's sort each of Fielding's restrictions.

Client-server

The first restriction specifies that the network has to consist ​​ of clients and servers. The server is a computer which has required resources, and the client is a computer which needs to interact with the resources which are stored on the server. When you dig on the Internet, your computer acts in a client role and sends HTTP requests to the server to get an information access and to work with it. The RESTful-system has to make operations in a client-server model even if the component periodically behaves as the client, as the server.

The alternative to the client-server architecture constructed without REST is the integration based on events. In this model, each component continuously transfers events, intercepting the corresponding events from other components. In it there is no interaction one - to - one, only transfer and interception. REST demands interaction one - to - one therefore the architecture based on events will not meet requirements of RESTful.

Lack of a status

The concept "without status" does not mean that servers and clients have no it, they just have no need to trace each other status. When the client does not interact with the server, the server has no idea of its existence. The server also does not keep account of last requests. Each request is reviewed as independent.

Uniformity of the interface

Restriction guarantees that between servers and clients there is common language which allows each part to be replaced or changed, without violation of integrity of system. It is reached through 4 subrestrictions: identification of resources, manipulation with resources through representations, "self-sufficient" messages and hypermedia.

1st restriction of the interface: determination of resources

The first subrestriction of "the unified interface" influences how resources are identified. In REST terminology anything can be a resource — HTML document, the image, information on the specific user, etc. Each resource has to be is unique is designated by the permanent identifier. "Permanent" means that the identifier will not change during data exchange, and even when the resource status will change. If other identifier is appropriated to a resource, the server has to tell the client that the request was unsuccessful and to give the reference to the new address.

Web uses URI for identification of resources, and HTTP — as the standard of communication. To receive the resource which is stored on the server the client does to URI HTTP-GET-request which identifies this resource. Every time when you gather some address in the browser, the browser does GET request for this URI. If the browser returns back 200 OK and HTML document, then the browser renders the page in a window, and you see it.

2nd restriction of the interface: resource management through representations

The second subrestriction of "the unified interface" says that the client manages resources, sending to the representation server, is normal in the form of the JSON object containing content which he would like to add, delete or change. In REST at the server complete control over resources, and he is responsible for any changes. When the client wants to make changes to resources, he sends to the server representation of what he sees a final resource. The server accepts request as the sentence, but behind it still there is complete control.

Let's consider the blog as an example. When the user creates a new post in the blog, its computer has to report to the server that in the blog it is necessary to add new entry. That to execute it, it sends HTTP-POST-request or PUT request with contents in the form of a new blog entry. The server returns the answer specifying that record is created or there was a problem. In a не-REST the world the client can give instructions to operations in literal sense, it seems "add a new line" and "to appropriate records the name", instead of normal sending representation of what he sees a final resource.

3rd restriction of the interface: self-sufficient messages
self-sufficient messages are one more restriction which guarantees commonality of the interface at clients and servers. Only the self-sufficient message contains all information which is necessary for understanding his receiver. In separate documentation or other message there should not be additional information.

To understand how it concerns WEB, let's analyze the HTTP set of requests and answers.

When the user types www.example.com in an address bar of the web browser, the browser sends the corresponding HTTP request:

GET / HTTP/1.1 Host: www.example.com

This self-sufficient message because it transfers to what server the HTTP method and what protocol (HTTP 1.1) was used.

The server can send the answer like it:

HTTP / 1.1 200 OK Content-Type: text/html <!DOCTYPE html> <html> <head> <title>Home Page</title> </head> </body> <div>Hello World!</div> <a href= “http://www.recurse.com”> Check out the Recurse Center! </a> <img src="awesome-pic.jpg"> </body> </html>

This self-sufficient message because it tells the client how to interpret the text of the message (thanks to Content-type = text/html). The client has everything that is necessary, in this one message for its processing as appropriate.

Imagine alternative communication option when the server sends the binary code in one answer, and then the separate message which speaks to the client how to interpret a binary code, the image it or a fragment of a code is not important. If two answers somehow are delivered in an incorrect order, or between them the third message will be inserted, then the client will get confused and will not be able correctly to interpret these messages.

4th restriction of the interface: hypermedia

The last restriction of the interface is a restriction of hypermedia. The hypermedia is a pathos concept for designation of data which contain information on what the client needs to do is farther, in other words, what else request he can make. Have to send to REST servers to clients only hypermedia.

HTML is one of types of hypermedia. That to understand it better, let's look once again at the answer of the server above.
<a href= “http://www.recurse.com”> Check out the Recurse Center!</a>
tells the client that he has to make GET request to www.recurse.com if the user clicks on the link.
<img src="awesome-pic.jpg">
speaks to the client immediately to make GET request to www.example.com/awesome-pic.jpg that that displayed the image for the user.

When the system has identifiers for each resource, manages them through the direction of representations from the client to the server, contains self-sufficient messages and is made of hypermedia, say that it has a unified interface. Perhaps, it is the most important RESTful attribute of system as it allows clients to adapt to changes. The server can change basic implementation, without tearing off all clients who interacted with it because each interaction is self-sufficient: identifiers do not change at change of basic statuses or implementation, and the hypermedia gives to clients of the instruction for transitions from a status to a status which it can perform afterwards. The server does not need to remember anything the client or to do something special to satisfy it and vice versa.

Other restrictions of Fielding: caching, system of layers and code on demand


There are three more restrictions of Fielding which we will consider briefly here.

Caching: answers of the server have to be marked as cached or not cached. The caching occurs when the client saves the answers received earlier from the server. When these data are necessary again, the caching can relieve of complete pass of data on a network. An opportunity to cache sushchesvut thanks to self-sufficient messages. The client does not need to worry that only the part of necessary information will accidentally be cached, and other parts will be lost.

The system of layers assumes existence of bigger quantity of components, than the client and the server. In system there can be more than one layer. Nevertheless, each component is limited to capability to see only the next layer and to interact only with it. The proxy is an additional component, it relays HTTP requests for servers or other proxies. Proxy servers can be useful to balancing of loading and checks of safety. The proxy works as the server for the initial client who sends request and then as the client when relays this request. The gateway is a one more additional component, it transfers HTTP request to other protocol, extends this request, and then transfers the received answer back to HTTP. The client can handle the gateway, as the normal server. An example of the gateway — system which loads files from the FTP server.

Code on demand — the only optional restriction which assumes sending by the server of executable code to the client. It is what occurs in the HTML tag
<script>
. When HTML document is loaded, the browser automatically selects on the JavaScript server and performs it locally.

* * *

In general, the RESTful system is any network which answers Fielding's restrictions. The RESTful-system has to be rather flexible for different scenarios of use, scaled for placement of a large number of users and components, and also adapted eventually. We considered as far as the Web meets the requirements of RESTful when business concerns interaction of the person and the browser. Development of Web interfaces on the basis of RESTful-architecture for intercomputer interactions is much more difficult subject (for additional information you watch the listed below resources). Remember that REST is a theoretical design and that Web which exists today, still sometimes falls short of the theory.

Next time you will not need to pretend that you know what actually means RESTful.

To reading



Transfer: Natalia Bass

This article is a translation of the original post at habrahabr.ru/post/274675/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: sysmagazine.com@gmail.com.

We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus