Http Verbs Details-Meaning & Usage

Hello friends, in our previous discussions, we discussed about What is Http, Usage and Important Terms. Today we are going to discuss about Http verbs details. We’ll see the differences, Implementation and Ideal usage for these.

What are HTTP Verbs?

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 as HTTP verbs.

Let’s discuss about these http verbs details.


The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. Requested resource is returned in form of xml or json.

Note: Get should be used only for retrieval. It should not change representation of any resource.

Additionally, GET APIs should be idempotent, which means that making multiple identical requests must produce same result every time until another API (POST or PUT) has changed the state of resource on server.

For any given HTTP GET API, if resource is found on server then it must return HTTP response code 200 (OK) – along with response body which is usually either XML of JSON content (due to their platform independent nature).

In case resource is NOT found on server then it must return HTTP response code 404 (NOT FOUND). Similarly, if it is determined that GET request itself is not correctly formed then server will return HTTP response code 400 (BAD REQUEST).

You can get more information about Http Status Codes here. 

Idempotent Methods:

The term idempotent is used more comprehensively to describe an operation that will produce the same results if executed once or multiple times.

Example request URIs:

HTTP GET http://www.example.com/users
HTTP GET http://www. example.com/users?size=20&page=5


The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

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.

Example request URIs:

HTTP HEAD http://www.example.com/users


POST is used to send data to a server to create/update a resource. The data sent to the server with POST is stored in the request body of the HTTP request.

Ideally, if a resource has been created on the origin server, the response SHOULD be HTTP response code 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

Many times, the action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either HTTP response code 200 (OK) or 204 (No Content) is the appropriate response status.

Some other notes on POST requests:

  • POST requests are never cached
  • POST requests do not remain in the browser history
  • POST requests cannot be bookmarked
  • POST requests have no restrictions on data length


POST /test/myform.php HTTP/1.1
Host: example.com


The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.

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. In addition to this POST requests are made of resource collections whereas PUT requests are made on individual resource.

If a new resource has been created by the PUT API, the origin server MUST inform the user agent via the HTTP response code 201 (Created) response and if an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.

Example request URIs:

HTTP PUT http://www.example.com/users/123


The DELETE method deletes the specified resource.

A successful response of DELETE requests SHOULD be HTTP response code

  • 200 (OK) – if the response includes an entity describing the status, 
  • 202 (Accepted) – if the action has been queued, or 
  • 204 (No Content) – if the action has been performed but the response does not include an entity.

DELETE operations are idempotent. If you DELETE a resource, it’s removed from collection of resource. Repeatedly calling DELETE API on that resource will not change the outcome – however calling DELETE on a resource a second time will return a 404 (NOT FOUND) since it was already removed.

Example request URIs:

HTTP DELETE http://www.appdomain.com/users/123


The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.

The HTTP TRACE method is designed for diagnostic purposes. If enabled, the web server will respond to requests that use the TRACE method by echoing in its response the exact request that was received.

This behavior is often harmless, but occasionally leads to the disclosure of sensitive information such as internal authentication headers appended by reverse proxies. This functionality could historically be used to bypass the Http Only cookie flag on cookies, but this is no longer possible in modern web browsers.

Example request URIs:

HTTP TRACE /mypage.html HTTP/1.1


The OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting ‘*’ instead of a specific resource.

To find out which request methods a server supports, one can use curl and issue an OPTIONS request:

curl -X OPTIONS http://example.com -i

The response then contains an Allow header with the allowed methods:

HTTP/1.1 200 OK
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0


The HTTP CONNECT method method starts two-way communications with the requested resource. It can be used to open a tunnel.

For example, the CONNECT method can be used to access websites that use SSL (HTTPS). The client asks an HTTP Proxy server to tunnel the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client.

CONNECT is a hop-by-hop method.

Hop by Hop: 

Indicates the flow the communication follows. Data pass through multiple devices with an IP address, and each is genetically named “hop”. Hop by Hop indicates analyzing the data flow at layer 3, checking all devices in the path.


CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80


The PATCH method applies partial modifications to a resource.

The HTTP PUT method only allows complete replacement of a document. Unlike PUT, PATCH is not idempotent, meaning successive identical patch requests may have different effects. However, it is possible to issue PATCH requests in such a way as to be idempotent.



PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100


A successful response is indicated with a 204 response code, because the response does not carry a message body.

HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"

All general-purpose HTTP servers are required to implement at least the GET and HEAD methods, and all other methods are considered optional by the specification.

Safe methods

Some of the methods (for example, HEAD, GET) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server.

This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested – and they can update/delete the resource on server and so should be used carefully.

Http verbs details



That’s all about Http verbs for this article.