In the realm of Rest API and their communication , one of the most important feature or concept is the use of HTTP verbs. If you do not know about what the HTTP verbs are, I would highly suggest you to go through this link that talks about the different HTTP verbs like GET, POST etc.
One of the lesser used and known HTTP verb is the HEAD request. I write lesser used because I’ve seen the implementation of this method being one of the very few places – both in my projects and also else where. There are teams where very experienced folks are not aware of what HEAD request is and what feature it brings to the table.
So let’s talk about this today.
HEAD REQUEST
The HEAD request method is similar to the GET method, but it only returns the header information of a resource. As per the MDN definition –
The HTTPHEADmethod requests the headers that would be returned if theHEADrequest’s URL was instead requested with the HTTPGETmethod.
The server will not return the body of the resource, only the HTTP headers. A HEAD request should not have a response body associated with it. If there is any associated response body anyways, then it must be ignored.
The response to a HEAD request will include the same headers as a GET request, but without the actual content. As such HEAD inherits some of the properties of the GET requests – like
- A
HEADrequest is aSAFEmethod. - A
HEADrequest is idempotent. - A
HEADrequest is cacheable.
SYNTAX
The HEAD request syntax almost looks identical to the GET request syntax
So Why Use HEAD?
This has been asked in so many times in the architecture calls and I’ve seen this in so many LinkedIn comments too, as to what is the use of the HEAD call when we already have a GET call.
Let’s see some scenarios where making a HEAD call is more beneficial then using the default GET call.
- Check if a resource is available
One common use of the HEAD request is to check if a resource is available on server. Since there is no overhead of the response body, a simple HEAD call with 200 status would confirm if the resource actually exists on the server.
For example, a web crawler might use a HEAD request to check if a website/ webpage is online before attempting to scrape its content. If the server returns a 200 OK status code, it means the website/webpage is available.
- Checking Resource Modification Date
Another use of the HEAD request is to check when a resource was last modified. The server can include the Last-Modified header in the response to a HEAD request, which contains the date and time when the resource was last modified. This information can be used to determine if a cached version of the resource is still valid.
- Getting Resource Size
The HEAD request can also be used to determine the size of a resource. The server can include the Content-Length header in the response to a HEAD request, which contains the size of the resource in bytes. This information can be useful in situations where the client needs to allocate memory to store the resource.
Another example of this is, if a URL might produce a large download, a HEAD request could read its Content-Length header to check the file-size without actually downloading the file. This can be helpful to put restrictions on the size of file to be downloaded on a system – if there is a requirement.
- Checking Authorization
The HEAD request can be used to check if a client is authorized to access a resource, without having the need to access the resource. The server can include the WWW-Authenticate header in the response to a HEAD request, which contains information on how to authenticate with the server.
This can be useful in situations where a client needs to check if it has permission to access a resource before attempting to access it.
- Reducing Network Overhead
The HEAD request can also be used to reduce network overhead. This can be helpful in situations when the only the information about the state of a resource is needed. In those situations, using a HEAD request instead of a GET request can save bandwidth and processing time.
As you can see from the above points, all-though small, there is a case where we can use the HEAD request to our own benefit. In most cases, when you don’t want the overhead of the response from the GET request, then you can use the HEAD request.
TESTEROPS 