| created on | May 28, 2026 |
As described in RFC 9110 / HTTP Semantics. The PATCH method is described in RFC 5789 (Proposed Standard). The PATCH method does not belong into the core HTTP request methods, but crops up occasionally in discussions about the application of request methods, which is why I included it here.
| method | function | safe | idempotent | cacheable |
|---|---|---|---|---|
| CONNECT | establish a secure tunnel through a proxy, often for HTTPS connections. primarily used when a proxy is used to access a remote resource. | x |
x |
x |
| DELETE | remove the association between the target resource and its current functionality; expected is a deletion operation on the URI mapping rather than the associated information. | x |
x |
|
| GET | request the transfer of a current selected representation for the target resource. | |||
| HEAD | identical to GET except that the server MUST NOT send content in the response; used to obtain metadata about the target resource without transferring its representation data. | |||
| OPTIONS | requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. | x |
||
| PATCH | apply a set of changes described in the request entity to be applied to the target resource identified by the Request-URI. | x |
conditional | |
| POST | the target resource processes the representation enclosed in the request according to the resource’s own specific semantics. | x |
x |
conditional |
| PUT | request that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message content. | x |
x |
|
| TRACE | performs a loop-back test along the path to the target resource. displays the request as seen by the final recipient; for testing or diagnostic information. | x |
POST and PATCH are cacheable when responses explicitly include freshness information ( header with a value) and a matching header.
All general-purpose servers must support the methods GET and HEAD. All other methods are optional.
RFC 9110 does not define status codes for all outcomes of all methods.
| method | on success | on failure |
|---|---|---|
| CONNECT | Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the response header section; data received after that header section is from the server identified by the request target. | Any response other than a successful response indicates that the tunnel has not yet been formed. |
| DELETE | 202 (Accepted) if the deletion has not been done, but will likely succeed; 204 (No Content) if the request has been fulfilled and no further information is to be supplied; 200 (OK) if the request has been enacted and the response message includes a representation describing the status. | Not defined in RFC 9110. |
| GET | 200 (OK) | Not defined in RFC 9110. Usually a 4xx, i.e. 404 (Not Found) |
| HEAD | Not defined in RFC 9110 | Not defined in RFC 9110 |
| OPTIONS | Not defined in RFC 9110 | Not defined in RFC 9110 |
| PATCH | 204 (No Content, but other success codes could be used as well. | 400 (Bad Request), 415 (Unsupported Media Type) 422 (Unprocessable Entity) |
| POST | Almost all status codes except 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable) are possible. Usually, a 201 (Created) with Location header providing an identifier for the primary resource created. | Not defined in RFC 9110 |
| PUT | 201 (Created) if a new resource has been created; 200 (OK) or 204 (No Content) if a resource has been modified. | RFC 9110 suggests 409 (Conflict) or 415 (Unsupported Media Type) |
| TRACE | 200 (OK), from the final recipient, reflecting the message received, excluding fields with sensitive data (i.e. authentication) | N/A |
The details are in RFC 9110. For POST:
" The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. "
RFC 9110, 9.4.3, POST
Whereas for PUT:
" The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message content. [...] A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server. "
RFC 9110, 9.4.4, PUT
And the difference between POST and PUT:
" The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. "
RFC 9110, 9.4.4, PUT
Example (some headers and the message bodies are omitted):
A client is posting a message in a forum for traveling.
The operation succeeds and the server replies with a 201 (Created) status code and a Location header pointing to the post – the resource that has been created by the request above.
The client can use the location in the Location header to update the post by replacing it completely with another version of its original post.
On success, the server will reply with status code 200 (OK) or 204 (No Content).
If the client wants to only partially change the post identified by the target resource (i.e., the headline of the post), it can send a PATCH request:
The content of the message contains the data for the changes. On successful change of the target resources, the server responds with a 204 (No Content) status code:
Note that the POST could also have been achieved with PUT.
In addition to the core HTTP request methods, there are request methods in different areas of application. Some of them are defined in RFC Proposals, some are vendor specific extensions. I list a few of them here:
IETF datatracker, RFC 9110 / HTTP Semantics
IETF datatracker, RFC 5789 / PATCH Method for HTTP
IETF, HTTP SEARCH Method