HTTP request types and REST philosophy
This post is the answer to a question asked in a comment to one of my articles.
In the article I want to tell you what HTTP-methods GET / POST / PUT / DELETE and others are, what they were designed for and how to use them in accordance with REST.
So, what is one of the main protocols of the Internet? I will send pedants to RFC2616 , and the rest I will tell humanly :)
This protocol describes the interaction between two computers (client and server), built on the basis of messages called Request (Request) and Response (Response). Each message consists of three parts: starting line, headers and body. In this case, only the start line is required.
')
The starting lines for the request and the response have a different format - we are only interested in the starting line of the request, which looks like this:
where METHOD is just an HTTP request method, URI is a resource identifier, VERSION is a protocol version (version 1.1 is currently relevant).
Headers are a set of name-value pairs, separated by a colon. Various service information is transmitted in the headers: the message encoding, the name and version of the browser, the address from which the client came (Referrer), and so on.
The message body is actually the data being transmitted. In the response, the transmitted data, as a rule, is the html page that the browser requested, and in the request, for example, the content of the files uploaded to the server is transmitted in the message body. But as a rule, the message body in the request is completely absent.
Consider an example.
Request:
The first line is the query string, the rest are the headers; message body missing
Answer:
Let's return to the start line of the request and recall that there is such a parameter as URI in it. This stands for Uniform Resource Identifier - a uniform resource identifier. A resource is, as a rule, a file on the server (an example of a URI in this case is '/styles.css'), but in general a resource can be an abstract object ('/ blogs / webdev /' - indicates the “Web development "and not on a specific file).
The type of HTTP request (also called HTTP method) indicates to the server what action we want to take with the resource. Initially (at the beginning of the 90s) it was assumed that the client may want only one thing from the resource - to receive it, but now you can create posts using HTTP protocol, edit a profile, delete messages and much more. And these actions are difficult to combine with the term “receiving.”
For differentiation of actions with resources at the level of HTTP-methods and the following options were invented:
Pay attention to the fact that the HTTP specification does not oblige the server to understand all the methods (of which there are actually much more than 4) - only GET is required, and also does not indicate to the server what it should do when receiving a request with this or that method. This means that the server in response to a DELETE request /index.php HTTP / 1.1 is not obliged to delete the index.php page on the server, just as on the GET request /index.php HTTP / 1.1 is not obliged to return the index.php page to you, he can delete it, for example :)
REST (REpresentational State Transfer) - this term was introduced in 2000 by Roy Fielding, one of the developers of the HTTP protocol, as the name of a group of web application building principles. In general, REST covers a wider area than HTTP — it can also be used in other networks with other protocols. REST describes the principles of interaction between the client and server, based on the concepts of "resource" and "verb" (you can understand them as subject and predicate). In the case of HTTP, the resource is determined by its URI, and the verb is the HTTP method.
REST suggests not using the same URI for different resources (i.e. the addresses of two different articles like /index.php?article_id=10 and /index.php?article_id=20 are not REST-way) and use different HTTP methods for different action. That is, a web application written using the REST approach will delete a resource when accessing it with the HTTP DELETE method (of course, this does not mean that you have to give the ability to delete everything and everyone, but any delete request in the application must use HTTP DELETE method).
REST gives programmers the ability to write standardized and slightly more beautiful web applications than before. Using REST, the URI for adding a new user will not be /user.php?action=create (GET / POST method), but simply /user.php (strictly POST method).
As a result, by combining the existing HTTP specification and the REST approach, various HTTP methods finally make sense. GET - returns a resource, POST - creates a new one, PUT - updates an existing one, DELETE - deletes.
Yes, there is a small problem with the use of REST in practice. This problem is called HTML.
PUT / DELETE requests can be sent via XMLHttpRequest, by contacting the server "manually" (say, through curl or even through telnet), but you cannot make an HTML form that sends a full PUT / DELETE request.
The fact is, the HTML specification does not allow you to create forms that send data differently than through GET or POST. Therefore, for normal work with other methods, it is necessary to imitate them artificially. For example, in Rack (the mechanism on which Ruby interacts with the web server; using Rack made Rails, Merb and other Ruby frameworks) you can add a hidden field with the name "_method" and specify the name of the method as a value (for example, “PUT”) - in this case, a POST request will be sent, but Rack will be able to pretend to receive a PUT, not a POST.
In the article I want to tell you what HTTP-methods GET / POST / PUT / DELETE and others are, what they were designed for and how to use them in accordance with REST.
HTTP
So, what is one of the main protocols of the Internet? I will send pedants to RFC2616 , and the rest I will tell humanly :)
This protocol describes the interaction between two computers (client and server), built on the basis of messages called Request (Request) and Response (Response). Each message consists of three parts: starting line, headers and body. In this case, only the start line is required.
')
The starting lines for the request and the response have a different format - we are only interested in the starting line of the request, which looks like this:
METHOD URI HTTP/ VERSION ,where METHOD is just an HTTP request method, URI is a resource identifier, VERSION is a protocol version (version 1.1 is currently relevant).
Headers are a set of name-value pairs, separated by a colon. Various service information is transmitted in the headers: the message encoding, the name and version of the browser, the address from which the client came (Referrer), and so on.
The message body is actually the data being transmitted. In the response, the transmitted data, as a rule, is the html page that the browser requested, and in the request, for example, the content of the files uploaded to the server is transmitted in the message body. But as a rule, the message body in the request is completely absent.
HTTP communication example
Consider an example.
Request:
GET /index.php http / 1.1 Host: example.com User-Agent: Mozilla / 5.0 (X11; U; Linux i686; ru; rv: 1.9b5) Gecko / 2008050509 Firefox / 3.0b5 Accept: text / html Connection: close
The first line is the query string, the rest are the headers; message body missing
Answer:
HTTP / 1.0 200 OK Server: nginx / 0.6.31 Content-Language: en Content-Type: text / html; charset = utf-8 Content-Length: 1234 Connection: close ... SAME HTML PAGE ...
Resources and Methods
Let's return to the start line of the request and recall that there is such a parameter as URI in it. This stands for Uniform Resource Identifier - a uniform resource identifier. A resource is, as a rule, a file on the server (an example of a URI in this case is '/styles.css'), but in general a resource can be an abstract object ('/ blogs / webdev /' - indicates the “Web development "and not on a specific file).
The type of HTTP request (also called HTTP method) indicates to the server what action we want to take with the resource. Initially (at the beginning of the 90s) it was assumed that the client may want only one thing from the resource - to receive it, but now you can create posts using HTTP protocol, edit a profile, delete messages and much more. And these actions are difficult to combine with the term “receiving.”
For differentiation of actions with resources at the level of HTTP-methods and the following options were invented:
- GET - getting a resource
- POST - creating a resource
- PUT - update resource
- DELETE - delete resource
Pay attention to the fact that the HTTP specification does not oblige the server to understand all the methods (of which there are actually much more than 4) - only GET is required, and also does not indicate to the server what it should do when receiving a request with this or that method. This means that the server in response to a DELETE request /index.php HTTP / 1.1 is not obliged to delete the index.php page on the server, just as on the GET request /index.php HTTP / 1.1 is not obliged to return the index.php page to you, he can delete it, for example :)
REST comes into play
REST (REpresentational State Transfer) - this term was introduced in 2000 by Roy Fielding, one of the developers of the HTTP protocol, as the name of a group of web application building principles. In general, REST covers a wider area than HTTP — it can also be used in other networks with other protocols. REST describes the principles of interaction between the client and server, based on the concepts of "resource" and "verb" (you can understand them as subject and predicate). In the case of HTTP, the resource is determined by its URI, and the verb is the HTTP method.
REST suggests not using the same URI for different resources (i.e. the addresses of two different articles like /index.php?article_id=10 and /index.php?article_id=20 are not REST-way) and use different HTTP methods for different action. That is, a web application written using the REST approach will delete a resource when accessing it with the HTTP DELETE method (of course, this does not mean that you have to give the ability to delete everything and everyone, but any delete request in the application must use HTTP DELETE method).
REST gives programmers the ability to write standardized and slightly more beautiful web applications than before. Using REST, the URI for adding a new user will not be /user.php?action=create (GET / POST method), but simply /user.php (strictly POST method).
As a result, by combining the existing HTTP specification and the REST approach, various HTTP methods finally make sense. GET - returns a resource, POST - creates a new one, PUT - updates an existing one, DELETE - deletes.
Problems?
Yes, there is a small problem with the use of REST in practice. This problem is called HTML.
PUT / DELETE requests can be sent via XMLHttpRequest, by contacting the server "manually" (say, through curl or even through telnet), but you cannot make an HTML form that sends a full PUT / DELETE request.
The fact is, the HTML specification does not allow you to create forms that send data differently than through GET or POST. Therefore, for normal work with other methods, it is necessary to imitate them artificially. For example, in Rack (the mechanism on which Ruby interacts with the web server; using Rack made Rails, Merb and other Ruby frameworks) you can add a hidden field with the name "_method" and specify the name of the method as a value (for example, “PUT”) - in this case, a POST request will be sent, but Rack will be able to pretend to receive a PUT, not a POST.
Source: https://habr.com/ru/post/50147/
All Articles