This article presents the theory related to HTTP methods. The main ones, GET and POST, were already discussed in the article about the HTTP protocol (click here to be redirected to the article), however, they will also be covered here.
GET and POST
The GET method asks the server to send web objects for a particular resource, such as a page. Web objects are the elements that make up a page, such as: text, image, video and even the page itself.
Another very common method, not so much as GET, is the POST method. In this case, the client is submitting information to the server. The server, in turn, receives and treats this information, which is sent encapsulated in the entity body field of the message. An intuitive example of the POST method would be filling out a form, or registering on a shopping website.
Note that as the server is required to handle post information, many sites place limitations on this method. A malicious user could use this field to send a Trojan, or malicious code to be executed on the server. Therefore, if you try to perform a POST request by an agent other than a browser, for example: a JAVA API, this request will return a disallow error.
Other HTTP Methods
In addition to the GET and POST methods, there are a variety of resource handling options, such as: head, put, delete, trace, among others. We will cover some of these methods with a brief explanation. If the reader wants to go deeper into this topic, references will be cited throughout the text.
Head
The HEAD method requests metadata information from a given resource. This method is useful to save bandwidth, by only checking if there was any modification to the resource since the last download. If the status is different from the one stored by the client, a new – request request is necessary.
Put and Delete
The PUT method determines that the information sent via entity body is stored by the resource. So what’s the difference between PUT and POST? In the case of the POST method, the information is just part of the process. This is a method of more general use, and can be applied in different situations, such as: identifying a resource and specifying commands to manipulate an attached entity, that is, the data can contain information or operations to be performed.
Still talking about the methods, we can mention the DELETE that obviously deletes a certain resource.
Trace
The TRACE method consists of a loop-back call of a given resource. This method allows the client to “see” the entire round-trip process of the request. Widely used in testing and diagnostic procedures related to server communication.
Option and Patch
The OPTION method describes to the client the configuration options related to a certain server resource. With CONNECT it is possible to determine a tunnel between the client and the target resource using SSL.
Our last method described is PATCH. This was defined after the HTTP 1.0 in the RFC 5789. When there is a need for a punctual modification of a certain resource, this method is used. If you want to go deeper into the HTTP methods, follow the link. link.
Secure HTTP Methods
Each method has a specialty, that is, some operation executed from its triggering. Some of these methods only request data from a server resource. These are called secure methods. A safe method is one that does not change the resource and, therefore, does not pose a risk to the server.
Safe methods are: GET, HEAD and OPTION. Since actions are executed from the client, it is intuitive to say that actions that a client might inflict on the server should be carefully considered.
Actions represent the interaction between client/server, which can be legitimate or malicious. With this in mind, an unsafe action can damage some server resource. For this reason, it is possible that a server does not accept requests from a different agent than the browser.
We can see this example happening when we perform a POST request through a JAVA API. In this case, a disallowed method status will be returned. However, the request is successful if performed through the browser containing the form. A GET method is not guaranteed to have no side effects on the server. However, it will not be the customer’s responsibility if any side effect occurs via a safe method.
Idempotent Methods
Every safe method is idempotent, but an idempotent method is not necessarily a safe method. Being an idempotent method means that the result originated by successive HTTP request actions will always have the same effect as a single request. Other examples of unsafe idempotent methods are: PUT and DELETE.
Bibliographic References
- HTTP Methods by Mozilla developer
- Kurose, James F., and Keith W. Ross. “Computer Networks and the Internet.” Pearson – 6° edition
- Tanenbaum, Andrew et al. “Computer Networks.” Pearson – 5° edition.
