Subbu:"Here is an addition to the list of anti-patterns that Stefan recently posted. The pattern is to let the client "think"
that is using verbs other than GET and POST, but piggyback such
requests over GET or POST. This was originally started by the GData folks via the X-HTTP-Method-Override header. Rails came along and baked its version for faking PUT, and DELETE over POST. [...] Patterns like this are misleadingly simple, and completely worthless."
Unfortunately I'm filing this under "not even wrong", even though it's Subbu. There's no antipattern here. The X-HTTP-Method-Override header and the approach Rails take are
decent ways to deal with misconfigured networks and broken as designed
specifications. Someday we won't need that kind of gorp, but that
someday is years off.
POST is the least specific method, and sometimes people, or in the case of WS-,* an entire industry, confuse that with the most generic method. Either way it's entirely suitable for qualification as a PUT/DELETE/etc call where PUT/DELETE/etc won't physically reach the server.
What? Well, the fact is, some networks will drop or block PUT/DELETE requests. Some widely deployed clients barely support HTTP properly (like J2ME). The mobile web in particular is riddled with these kinds of problems. It's intensely frustrating to see such a large number of clients left swinging in the wind. It can be very tempting to give up on the HTTP method set as fruitless purism and just run all the side effects as POSTs.
The argument that operators drop these methods the floor for a
reason and developers shouldn't be tunnelling other methods through
POST like this holds no water for me. Operators by that logic should be
blocking POST because it's less specific.
HTML forms are different. In that case the use of some HTTP methods
is outlawed by design. I've claimed before this is one of the worst
technical decisions made in web technology. So many other technologies
have derived their uniform set from HTML forms.
Operationally what does it mean to just use POST? It means don't even try speccing in AtomPub, or DAV. It means putting actions in URLs. The knock on problem of bad specs and bad networks is not so much method tunneling (though I diasgree with a policy that says "give up" rather than "tunnel as needed"). It's that when you drop into the RPC style you naturally tend to stop identifying objects with URLs and just call methods with id arguments. That makes a web based system harder to manage and its data less useful.
Previous Topic
