HTTP Methods: The HTTP defines a set of request methods that indicate desired actions to be performed for a given resource. Even if they are nouns, the request methods are commonly called HTTP verbs. These HTTP verbs are case sensitive and must be used in uppercase. Each and every HTTP Methods establishes different meaning, but some common features are shared by a group of them. For example, the HTTP request methods are safe, idempotent and cacheable.
Although this set of HTTP verbs can be expanded, additional request methods cannot be assumed to share the same semantics for separately extended clients and servers. Below are the HTTP Methods and their request methods in detail.
The GET method is used to retrieve the information from the requested URL. The GET method should only retrieve data and should not have any effect on the data. Thus calling a request multiple times won’t affect the data and has an effect as the same when they are called once. To point out, GET method is idempotent which means making multiple request results in ending up like a single request. Usually, GET returns a representation in XML or JSON and an HTTP response code of 200 OK. In an error case, it most often returns a 404 Not Found or 400 Bad Request.
If the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field the semantics of the GET method changes to a “Conditional GET”. The conditional GET method requests can be transferred only when conditional header fields are available. It is intended to reduce the unnecessary network usage by using cached entities.
If the request message includes a Range header field then the semantics of GET method changes to “Partial GET”. It is also intended to reduce network similar to conditional GET as it requests for only a part of the entity being transferred.
The HEAD method is same as that of GET except that the server doesn’t return any message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This HEAD method can be used to obtain meta-information about the request without transferring the entity-body. This method is often used for testing hypertext links for validity, accessibility, and recent modification.
The HEAD response method is cacheable so that the information contained can be used to update previously cached entity from that resource. If the new file values state that the cached data is different from the present data, then the cache is treated as an old one.
The POST method is used to request the server to accept a new entity as a new subordinate. To point out it is used to create subordinates that are subordinate to some other parent resource. It is often used to make changes in the state or side effects on the server. So when you are creating a new resource, POST to the parent resource and it takes care of assigning and associating the resources.
On successful creation of the resource, return an HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.
The POST method takes cares of the following functions:
- Providing a block of data, as the result of submitting a form to a data-handling process
- Extending a database through an append operation
- Annotation of existing resources
- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles
The POST method is dependent on the Request-URI. The new entity is subordinate to that URL the same way a file is subordinate to a directory. The action performed by the POST method might not result in a resource that can be identified by a URI. Now either 200 OK or 204 No Content is the appropriate response status based on the response that describes the result. If a resource has been created on the origin server, then the response should be 201 Created.
The response to the POST method is not cacheable unless the response includes a Cache-Control or Expires header fields. You can also use 303 See Other to direct the user to retrace a cacheable resource.
The PUT method is used to update the target resources with the enclosed entity from the request payload. It is most frequently used for updating purposes. The known resource URL is replaced with the newly updated data of the request body. The PUT method requests to store the enclosed entity with the Request-URL. If it already persists, the enclosed entity is considered as a modified resource with the one present in the origin server. If the Request-URL does not point to the existing resource and if the URL is capable of being defined as a new resource, then the server can create a new entity with that URL.
In case of a new resource being created then the origin server should inform the user using 201 Created status code. In case of the existing resource being modified then either 200 OK status code or 204 No Content should be used to represent successful completion of the request. If the resource could not be created or modified as per the Request-URL, then the corresponding error code must be given to the user. Also, a 501 Not Implemented response is used in cases that the recipient’s headers gets ignored.
The PUT method is not to use as it modifies the state on the server, yet it is idempotent. Create a resource using PUT and make a call, again and again, it will have the same state as it had with the first call. It is highly recommended to use PUT method for idempotent requests and to use POST method for non-idempotent requests.
The delete works the same way as it means, it deletes the resources identified by the Request-URL. This PUT method can be overridden or interrupted by human intervention or any other means on the origin server. It is not guaranteed that operation is completed successfully even if the status code from the origin server states success. Thus the server should not post success unless the response is given that the resource is deleted and moved to a location that is inaccessible.
A successful response is returned with 200 OK including a description of the status. Or a 202 Accepted status if the action is yet to be performed. Else a 204 No Content if the action has been enacted, but the server response does not include any entity.
The DELETE method is idempotent that is if you delete a resource it is removed. Even if you call DELETE multiple times, it ends up on the same. IF calling DELETE decrements a counter then no longer DELETE is idempotent. It is recommended to use POST for non-idempotent resource requests.
Calling DELETE on a resource for the second time will often return a 404 NOT FOUND as it was already removed and no longer available. This in some notion makes DELETE operations no longer idempotent. However, the final state is the same.
The TRACE method uses an application layer message loop-back of the request method. The end recipient SHOULD reflect back the message to the client as a 200 OK response. The final recipient is the either the first proxy or the origin server or the gateway to receive a Max-Forwards value of zero.
The TRACE method MUST NOT include an entity. The TRACE method allows the client to see what is being received at the other end of the request chain and use that data for testing information. The value of the Via header acts as the trace of the request chain. The Max-Forwards header field allows the client to lessen the length of the request chain. This will be useful for testing a chain of proxies forwarding messages in an infinite loop. If the request is valid, then the response SHOULD contain the entire request message in the entity-body, with a Content-Type of “message/http”. Responses to this method MUST NOT be cached.
The CONNECT METHOD is referred to proxies that dynamically establishes a tunnel to the server identified by the target resource.
Learn more about HTTP Methods for HTTP Error Codes.
Other HTTP Status Codes
207 Multi-Status (WebDAV; RFC 4918)
208 Already Reported (WebDAV; RFC 5842)
226 IM Used (RFC 3229)
300 Multiple Choice
304 Not Modified
305 Use Proxy
308 Temporary Redirect
4xx Client Error
402 Payment Required
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot (RFC 2324)
421 Misdirected Request
422 Unprocessable Entity (WebDAV; RFC 4918)
423 Locked (WebDAV; RFC 4918)
424 Failed Dependency (WebDAV; RFC 4918)
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
451 Unavailable For Legal Reasons
5xx Server Error
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Variant Also Negotiates
508 Loop Detected (WebDAV; RFC 5842)
510 Not Extended (RFC 2774)
511 Network Authentication Required
Unofficial Error Code List
420 Method Failure (Spring Framework)
420 Enhance Your Calm (Twitter)
450 Blocked by Windows Parental Controls (Microsoft)
498 Invalid Token (Esri)
499 Token Required (Esri)
499 Request forbidden by antivirus
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)
530 Site is frozen
Internet Information Services Error Code List
449 Retry With
444 No Response
Nginx Error Code List
495 SSL Certificate Error
496 SSL Certificate Required
497 HTTP Request Sent to HTTPS Port
499 Client Closed Request
CloudFlare Error Code List
520 Unknown Error
521 Web Server Is Down
522 Connection Timed Out
523 Origin Is Unreachable
524 A Timeout Occurred
525 SSL Handshake Failed
526 Invalid SSL Certificate