Ending HTTP Abuse

In Jon Udell’s End HTTP Abuse piece he observes, as have many recently, that many of the popular web services don’t do the right thing with GET and POST. In my paper for XTech this was one of the criteria I used to compare a number of different web services.

The complete list of reviewed services comprises: del.icio.us, flickr, bloglines, upcoming, 43things, musicbrainz, audioscrobbler/last.FM, and WebJay. The list originally included AllConsuming but the site has/is going through a complete rewrite and had to be dropped for now.
One of my aims for the paper was to help foster a community of practice among developers by comparing and contrasting the designs of each service along several different axes. I’ve attempted to highlight areas, like GET/POST handling, where the services fall short of meeting the REST architecture or just simply following the letter of the HTTP specification.
The complete list of review criteria includes: URI design; use of HTTP methods; correct use of status codes (another patchy area); authentication, and API tokens; use of hypermedia; data formats; exposure of personal data; and licensing of both the service and it’s data. I think all of these criteria are important considerations when designing not only REST interfaces.
My conclusions about proper handling of GET/POST differ from Udell’s. In the above piece he writes:

Why didn’t Bloglines, Flickr, or del.icio.us enforce the POST restriction? I suspect it’s because they wanted their APIs to have the broadest possible reach. And from a programmer’s perspective, the simplest and easiest HTTP clients are those that use GET.

He then continues by exploring the ease of using GET versus POST on the client-side. I think the fault actually lies on the server-side. Specifically, with existing web applications frameworks.
In the Java world we’ve got Java Servlets. And what’s the most commonly implemented method? It’s not doGet its the generic service method. Thats the point at which the majority of frameworks hook into a Controller servlet to dispatch to server-side request handlers.
And yet, how many frameworks encourage or even allow the binding of handlers based on a combination of URL+method? In my experience the protocol independence anti-pattern kicks in at that point, and the request method is the last thing that a developer is encouraged to take into account. The end result are URLs that react identically to any request method. It might be an interesting experiment if Udell tried sending PUT, DELETE, HEAD requests to the same API calls.
This situation is often compounded by URL designs that are more RPC than REST in nature. E.g. /getPerson, /updatePerson rather than just /person. In the latter case you have to use the right request method to differentiate requests and respond appropriately.
I think a lot more attention needs to be paid to web application frameworks to address some of these issues. In the Java world even recent specifications like JavaServer Faces fall short in some fairly fundamental areas.
As Udell notes, after more than a decade we’re still working out how best to use HTTP. And that has to translate into closer attention to our toolkits and, where necessary, ripping them out and replacing them with something better.