http HEAD vs GET performance

A RESTful URI should represent a “resource” at the server. Resources are often stored as a record in a database or a file on the filesystem. Unless the resource is large or is slow to retrieve at the server, you might not see a measurable gain by using HEAD instead of GET. It could be that retrieving the meta data is not any faster than retrieving the entire resource.

You could implement both options and benchmark them to see which is faster, but rather than micro-optimize, I would focus on designing the ideal REST interface. A clean REST API is usually more valuable in the long run than a kludgey API that may or may not be faster. I’m not discouraging the use of HEAD, just suggesting that you only use it if it’s the “right” design.

If the information you need really is meta data about a resource that can be represented nicely in the HTTP headers, or to check if the resource exists or not, HEAD might work nicely.

For example, suppose you want to check if resource 123 exists. A 200 means “yes” and a 404 means “no”:

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

However, if the “yes” or “no” you want from your REST service is a part of the resource itself, rather than meta data, you should use GET.

Leave a Comment