Saturday, 22 October 2005
Why Just GET and POST?
Why is it that Web browsers — Amaya excluded — don’t support PUT and DELETE? After all, if there are enough VCs foolish enough to part with their money for something like Flock, surely we could at least support all of HTTP’s methods.
It’s not just browsers, of course; heck, even Python’s new, mega-complete urllib2 library restricts itself to GET and POST. Other languages are similarly limited. So, why does the implemented Web restrict itself to half of CRUD?
It’s not that these specs and tools aren’t “RESTful”; REST doesn’t specify GET/POST/PUT/DELETE or CRUD directly; it only talks about “uniform interface semantics.”
The trivial answer is that HTML only talks about GET and POST; it even took prodding to get XForms to expand its horizons. This just shifts the question, however; surely, if PUT and DELETE have utility, there would be demand for their support. Interestingly, that hasn’t happened to date; Web applications are being written and used just fine without them, thank you very much.
I think the real reason has to do with loose coupling.
Think about the difference between POST and PUT; the former is a “process this” function that might result in the representation being sent becoming available pretty much anywhere, while the latter very specifically says “put this here.” POST keeps the server in control of the URI space, while PUT effectively gives it to the client.
What does this have to do with loose coupling? When you move beyond using HTTP for just storing and viewing documents, it requires a lot of co-ordination regarding URIs. Just as two-phase commit isn’t such a hot idea in Internet-scale transactions, where you cross administrative boundaries and are exposing non-trival resources to the whim of others, giving clients control of the URI space is a commitment that, to date, few servers have been willing to make.
I often find it helpful to imagine exposing RESTful applications as a filesystem; GET, PUT and DELETE have their obvious counterparts, and POST roughly corresponds to a drop box. Is it any wonder that most Web sites aren’t willing to give write access to the world without some kind of control — like that kept by POST?
Moving forward, I think that we’ll see more PUT and DELETE, both inside the Intranet and within Internet-scale applications that have some means of both managing trust and describing resources to offset the tighter coupling brought about by giving the client more control. The benefits is greater visibility, with intriguing possibilities for scalability.
For us to get there, the tools and specs need to catch up. On the spec side, there are some interesting efforts in the IETF, including the Atom Publishing Protocol and CalDAV. Web description will also help, in a more generic way. These protocols and the formats they describe will show where to PUT and DELETE things, and more importantly, what it means to do so.
On the tool side, it’s pretty much roll-your-own for the time being, but I’m hopeful that once treating a Web application as more than just UI catches on (as it is in many places, like del.icio.us’ API) the demand will drive innovation.