HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. Although they can also be nouns, these request methods are sometimes referred to as HTTP verbs. Each of them implements a different semantic, but some common features are shared by a group of them: e.g. a request method can be safe, idempotent, or cacheable.
As per IANA there are around 40 HTTP Methods. Few of frequently used are mentioned below:
- GET: The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
- POST: The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.
- DELETE: The DELETE method deletes the specified resource.
- PUT: PUT is used to send data to a server to create/update a resource. The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.
- PATCH: The PATCH method is used to apply partial modifications to a resource. A PATCH request is similar to POST and PUT. However, its primary purpose is to apply partial modifications to the resource. And just like a POST request, the PATCH request is also non-idempotent. Additionally, unlike POST and PUT which require a full user entity, with PATCH requests, you may only send the updated username.
- OPTIONS: The OPTIONS method is used to describe the communication options for the target resource.
- HEAD: HEAD is almost identical to GET, but without the response body. The HEAD request method is useful in recovering meta-data that is written according to the headers, without transferring the entire content. The technique is commonly used when testing hypertext links for accessibility, validity, and recent modification. In other words, if GET /users returns a list of users, then HEAD /users will make the same request but will not return the list of users. HEAD requests are useful for checking what a GET request will return before actually making a GET request - like before downloading a large file or response body.
- CONNECT: The CONNECT method establishes a tunnel to the server identified by the target resource. The CONNECT request method is used by the client to create a network connection to a web server over a particular HTTP. A good example is SSL tunneling. In a nutshell, CONNECT request establishes a tunnel to the server identified by a specific URL.
- TRACE: The TRACE method performs a message loop-back test along the path to the target resource. TRACE requests are used to invoke a remote, application loop-back test along the path to the target resource. The TRACE method allows clients to view whatever message is being received at the other end of the request chain so that they can use the information for testing or diagnostic functions.
HTTP Request Method Summary
|HTTP method||RFC||Request has Body||Response has Body||Safe||Idempotent||Cacheable|
- RFC: Request for Comments (RFC), in information and communications technology, is a type of text document from the technology community. An RFC document may come from many bodies including from the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), or from independent authors. The RFC system is supported by the Internet Society (ISOC).
- Safe: Safe methods are HTTP methods that do not modify resources. A portion of the strategies (for instance, HEAD, GET, OPTIONS and TRACE) are, by tradition, characterized as protected, which implies they are expected just for data recovery and ought not change the condition of the server. By contrast, techniques, for example, POST, PUT, DELETE, and PATCH are expected activities that may bring about effects either on the server, or outer reactions.
- Idempotent: An idempotent HTTP method is a HTTP method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself.