When you think about it, any application can represent every piece of information coming from the outside world in unified data structure. That is, there is no real difference between headers, parameters, and body content (except, of course, in those cases where it is self-referential - for example, when a header tells you how to interpret the rest of the message. But even then one can write a totally generic function that does that first pass for you). When modeled this way, there's really not even a useful difference between GET and POST. These days all GETs cause writes to occur anyway, even if they are just analytics.
Indeed, I'm constantly surprised that there aren't more "grand unified APIs" for dealing with HTTP. If there were, then we'd have better consensus on just how useless a lot of the HTTP spec has become, verbs included. It reminds me of the Java Servlet API - much of it became worthless with the advent of Struts and SpringMVC, as the front controller pattern better fit the mental model of people writing applications.
That said, GET, POST and HEAD are probably worth keeping around, because at least the first two imply something about the kind of idempotency your callers should expect, which is useful.
Why can't GET support that process? You'd have the extra bytes of the content, but there's nothing stopping the server sending the Link header in response to a GET request.
Yes, it's used a lot. If you look through web server logs, you'll see tons of cases where a search engine spider performs a HEAD, and then based on the headers, it decides whether the content has changed since last fetched. If so, it issues a GET.
Say you have a list of downloads, and you want to know how big they are. With HEAD and Content-Length, you can know, in a standard fashion, assuming the server tells you. Isn't this basic enough, that you'd want to put it in HTTP? What else would you do? Application-specific file-size queries? Doing a GET and then just closing the connection after headers? That's not pretty!
That makes sense. I was not challenging the inclusion of HEAD in the http verbs, just stating my own ignorance and hoping for illumination, which you and others and have now provided. I appreciate it.
Indeed, I'm constantly surprised that there aren't more "grand unified APIs" for dealing with HTTP. If there were, then we'd have better consensus on just how useless a lot of the HTTP spec has become, verbs included. It reminds me of the Java Servlet API - much of it became worthless with the advent of Struts and SpringMVC, as the front controller pattern better fit the mental model of people writing applications.
That said, GET, POST and HEAD are probably worth keeping around, because at least the first two imply something about the kind of idempotency your callers should expect, which is useful.