With the rise of REST as a legitimate design methodology, and its first-class support in Rails, no longer are the lesser known
DELETE http request methods languishing in obscurity. The awareness of REST has brought them to the forefront, completing the quad-fecta of
But… there’s more. Yes, there are actually eight http request methods defined by the HTTP 1.1 spec. And why don’t we hear much of those other four request methods? Well, they’re of varying levels of usefulness to us as application developers (note that’s ‘varying’, not ‘negligible’). So here is my attempt to bring these ignored requests into the light so you can at least make your own decision as to their usefulness – and make an informed decision rather than one of ignorance.
Think of the
HEAD request method as a metadata request. You’re asking for the headers of a
GET request for the same resource without getting the resource itself. This lets you see things like the size of the resource being requested, the last-modified date of the resource and any other request headers associated with the resource without actually incurring the overhead of sending the resource across the wire.
As an example, the Amazon S3 service uses a
HEAD request to view information about a stored object like its size and permissions without getting the whole object. As these S3 objects represent files you can see how valuable
HEAD is as you wouldn’t want to download a 1Gb file just to see the properties of that file.
In the absence of human-consumable documentation, it’s tough to know what methods are supported by a particular service. For example, how do I know if I can call
HEAD on a resource URI? And even in the presence of complete developer documentation, wouldn’t it be great if you could just point to a root URI and programatically interrogate the service to determine its capabilities? Yeah, that would be great and would really open up a new world of simple but semi-automated REST-based services. This is what
OPTIONS attempts to do.
Unfortunately, there’s some ambiguity in the request/response spec of the
OPTIONS request method. The spec itself is tight lipped about what a response looks like and even how to properly request the server capabilities. There this page-turning proposal that attempts to clear up these ambiguities, but it’s a bit outdated and I don’t know if was accepted or rejected.
This seems to be a particularly useful and important request method, I’d love to dig a little deeper into this to see how it’s being used out there in the wild. If you have any such pointers, please post them here.
TRACE appears to be very similar to your
traceroute unix command. It is “used to invoke a remote, application-layer loop back of the request message”. And how is the traveled path conveyed back to the sender? Well, the response will have a
Via header value that will contain each node along the path. So instead of seeing a printout on your command line like
traceroute, you can just dump the
Via header contents which will look something like this (where ricky, mertz etc… are machine names):
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
It’s important to note this is not identical to
traceroute in that it won’t show you the hops along the IP route, it just shows you what happens within the remote service routing.
CONNECT is apparently a way to request that web proxies dynamically switch to a secure IP-based connection, like an SSL tunnel. This seems particularly out of place as it operates more on the protocol level and not really on the underlying resource (as does
TRACE to a certain extent). Hey, I didn’t write the thing.
Interesting huh? Yeah, didn’t think so – but it’s important to see the full picture of http and not just what web browsers or your particular application framework expose… and now you have that luxury.