HTTP METHODS
HTTP Methods define the action desired to be performed on a given resource. They are also referred to as HTTP Verbs.
Some HTTP methods are safe. It means that they should do not have significance of taking an action other than retrieval. Examples include GET and HEAD.
A method is also said to be idempotent if it can raise a sequence without side effects. A chain of GET requests for example, could fail to have side effects provided that no concurrent operations are being executed on the same resource.
We are going to get into details of some of the HTTP Methods as discussed in the HTTP/1.1 RFC .
OPTIONS
It allows the client to determine the options or requirements associated with a resource — rather, the capabilities of the server.
A client can specify a URL with this request or an asterisk to refer to the entire server.
It is a safe and idempotent method.
GET
It represents a retrieval of information from a Request-URI. The response of a GET request is cacheable — only if the caching standards are met.
GET requests should not include data. It is a safe method and its usage should be restricted to data retrieval.
It is also idempotent.
HEAD
The HEAD method asks for a response identical with the GET method but without the response body — if it has a body, it should be ignored.
The HTTP headers returned for the request should be identical as the ones that would be returned for a GET request to the same resource.
If a header in the response to a HEAD request shows that a cached URL response is outdated, it should be invalidated even if no GET request was made.
It is a safe, idempotent and cacheable method.
POST
It sends data to the server. The type of the body sent is indicated by the Content-Type header.
It is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources
- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles
- Providing a block of data, such as the result of submitting a form, to a data-handling process
- Providing a block of data, such as the result of submitting a form, to a data-handling process
It is not a safe method. It is also not idempotent.
PUT
It creates a new resource or updates an existing one with the request payload sent.
The difference between POST and PUT is that PUT is idempotent — calling it several times successively has the same effect.
It is not a safe method. It is also not cacheable.
DELETE
It deletes the specified resource. It may be overriden by human intervention or by other means on the origin server.
The client cannot be guaranteed of the action. However, the server should only give a successful response if it intends to complete the action.
It is definitely not a safe method. It is idempotent and not cacheable.
TRACE
It performs a message loop-back test along the path to the target resource, providing a useful debugging mechanism.
The final recipient of the request should reflect the message received, excluding some fields described below, back to the client as the message body of a 200 (OK) response with a Content-Type of message/http
The final recipient is either the origin server or the first server to receive a Max-Forwards value of 0 in the request.
It is safe and idempotent but not cacheable.
PATCH
It applies partial modifications to a resource. It is considered a set of instructions on how to update a resource rather than PUT which is a complete representation of the resource.
