HTTP defines request methods to indicate the desired action to be performed for a given resource. These methods are sometimes referred to as HTTP verbs, although they can also be nouns (e.g. HEAD and OPTIONS). Often, the resource in consideration, corresponds to a file or an output of an executable residing on the server. By convention, standardized methods are defined in all-uppercase ASCII letters, because they might be used as a gateway to object-based systems with case-sensitive method names. In addition, any client can use any method and the server can be configured to support any combination of methods.
Once a standardized method is defined, it will have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are implemented or allowed. Each method implements a different semantics, but some common features are shared by a group of methods, these are safe, idempotent, or cacheable.
Safe
An HTTP method is safe if a request using this method doesn’t alter the state of the server. In other words, it leads to a read-only operation. By calling a safe method, the client doesn’t request any server change, and therefore won’t create an unnecessary load or burden for the server. Although the servers can still alter their state by keeping logs or statistics. What is important here is browsers can call safe methods without fearing to cause any harm, loss of property, or unusual burden on the origin server; this allows them to perform activities like pre-fetching without risk. Web crawlers also rely on calling safe methods.
- safe methods: GET, HEAD, OPTIONS, TRACE
- unsafe methods: POST, PUT, DELETE, CONNECT, PATCH
Idempotent
An HTTP method is idempotent if multiple identical requests using this method will have the same effect on the server as that of a single request of that same method. In other words, an idempotent method should not have any side-effects, except for keeping logs and statistics. All safe methods are also idempotent, but not all idempotent methods are safe. To be idempotent, only the actual back-end state of the server is considered, the status code returned by each request may differ. For example, the first call of a DELETE will likely return a 200, while successive ones will likely return a 404.
- idempotent methods: GET, HEAD, PUT, DELETE, OPTIONS, TRACE
- non-idempotent methods: POST, CONNECT, PATCH
Cacheable
An HTTP method is cacheable if the response to a request using this method is allowed to be stored for future use, i.e. cached. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable, hence GET, and HEAD as cacheable. In general, these are the following constraints for an HTTP response to be cached:
- The method used in the request is itself cacheable, i.e. a GET or a HEAD method. However, a response to a POST request can also be cached if freshness is indicated and the Content-Location header is set.
- Methods like PUT or DELETE are not cacheable, and their result cannot be cached.
- The status code of the response is known by the application caching, and it is considered cacheable. The following status codes are cacheable: 200, 203, 204 (an ETag header will be included), 206, 300, 301, 302 (if indicated by a Cache-Control or Expires header), 404, 405, 410, 414, and 501 (unless caching headers instruct otherwise). Check this article to learn more about HTTP status codes.
- There are specific headers in the response, like Cache-Control, that prevent caching.
When both, the method of the request and the status of the response, are cacheable, the response to the request can be cached.
- cacheable methods: GET, HEAD (sometimes POST)
- non-cacheable methods: POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH
Below are the definitions of the 9 standardized request methods that are commonly used in HTTP:
1. GET
The GET method requests to transfer a representation of a target resource. GET requests only retrieve data and will have no other effect. The GET method is safe, idempotent, and cacheable.
If the resource is found on the server, then the server will return HTTP response status code 200 (OK), together with the response body, which is usually either XML or JSON content. However, in case a resource is not found on the server then the server will return 404 (NOT FOUND). Similarly, if it is determined that the GET request itself is not correctly formed then the server will return 400 (BAD REQUEST).
2. HEAD
The HEAD method requests similar to that of the GET method, but without the representation data enclosed in the response body. This is useful for retrieving the representation metadata in the response header, without having to transfer the entire representation. The HEAD method is safe, idempotent, and cacheable.
The HTTP response status codes that will be returned by calling a HEAD method follows the same pattern as the GET method, but with the absence of the response body.
3. POST
The POST method requests to submit and process the representation enclosed in the request to a target resource. The data submitted often create an effect on the server. A POST request is typically sent via an HTML form and results in a change on the server. For example, it is used for signing up an account to a web application, posting a message to an Internet forum, or completing an online shopping transaction. The POST method is ussafe, non-idempotent, and cacheable only if freshness information is included.
If a resource has been created on the server, then the server will return HTTP response status code 201 (Created) together with an entity which refers to the new resource, and a Location header. However, in most cases, if the action performed by the POST method resulted in a resource that cannot be identified in a URI, then 200 (OK) or 204 (No Content) is the appropriate response status.
4. PUT
The PUT method requests to create a new resource or replaces a representation of the target resource with the state defined by the representation enclosed in the request (or request payload). Calling the PUT method once or several times successively will have the same effect (i.e. PUT is idempotent), while successive identical POST may have additional effects. The PUT method is unsafe, idempotent, and non-cacheable.
If a new resource has been created, then the server will return HTTP response status code 201 (Created). However, if an existing resource is modified, it will return either 200 (OK) or 204 (No Content).
5. DELETE
The DELETE method requests to delete a target resource. The DELETE method is unsafe, idempotent, and non-cacheable.
If a resource has been successfully deleted together with an entity describing what has been deleted, then the server will return HTTP response code 200 (OK). But in most cases, if the action has been performed and the response does not include the entity, then 204 (No Content) will be returned. And, if the action has been queued, then 202 (Accepted) can also be returned. In addition, repeatedly calling the DELETE on the same resource will not produce a new outcome, hence it will return a 404 (Not Found) on the succeeding requests since the resource has already been removed.
6. CONNECT
The CONNECT method requests to establish a TCP/IP tunnel to the origin server identified by the request target. It is used to secure two-way communication through one or more HTTP proxies with SSL/TLS. The CONNECT method is unsafe, non-idempotent, and non-cacheable.
If the connection was allowed and the proxy has connected to the specified host then the proxy will return HTTP response code 200 (OK).
7. OPTIONS
The OPTIONS method requests to identify the HTTP methods (“communication options”) that the target resource supports. This can be used to check the functionality of a web server by specifying a URL with this method, or an asterisk (*). The supported HTTP methods are returned on the Allow header. The OPTIONS method is safe, idempotent, and non-cacheable.
If communication options are implemented by the server and are applicable to the given resource, then the server will return HTTP response status code 200 (OK), together with the Allow header field. If there is a response body, this should also include information about the communication options.
8. TRACE
The TRACE method requests to perform a message loop-back test along the path to the target resource. That way a client can see if there are any changes or additions that have been made by intermediaries. This method provides a useful debugging mechanism. The TRACE method is safe, idempotent, and non-cacheable.
If the message is received back by the client, then it will return HTTP response status code 200 (OK) together with a Content-Type of message/http.
9. PATCH
The PATCH method requests to apply a modification to a target resource according to the partial update defined in the representation enclosed in the request. A PATCH request is considered a set of instructions on how to modify a resource, unlike PUT which is a complete representation of a resource. The PATCH method is unsafe, non-idempotent, and non-cacheable.
If the modification was successful and contained a payload body, then the server will return HTTP response status code 200 (OK) response could have contained a payload body. However, if without a payload body, then it will return 204 (No content).