mark nottingham

Why Just GET and POST?

Saturday, 22 October 2005

HTTP APIs

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.


10 Comments

Randy Charles Morin said:

I think you had the answer when you said that “HTML only talks about GET and POST.” Has anybody asked the working group why they made that decision? Has anybody on that committee published a reason?

Saturday, October 22 2005 at 2:40 AM

Bill de hOra said:

“Why Just GET and POST?”

HTML forms.

http://www.dehora.net/journal/2003/07/html_subsets_http_breaks_web_architecture_movie_at_11.html

Saturday, October 22 2005 at 5:39 AM

Anne van Kesteren said:

HTML forms (Web Forms) have been extended: http://whatwg.org/specs/web-forms/current-work/#methodAndEnctypes

Sunday, October 23 2005 at 2:06 AM

Mark Baker said:

Pretty much, Mark. That’s why RDF Forms only supports GET & POST. The very nature of a form is such that the server controls the meaning of the interaction.

On the other hand, if the server can provide additional information in the form which can make the client construct a more semantically meaningful message from the server’s POV - even if the client didn’t “mean it” - then other advantages are realized such as improved visibility for intermediaries. For example, if an HTML form could provide information necessary to enable a browser to construct a PUT message for a Wiki edit, then that would be advantageous from a visibility POV. That’s why I’m adding PUT support to RDF Forms. 8-)

Sunday, October 23 2005 at 4:59 AM

Aristotle Pagaltzis said:

Does the server really give up control of its URI space? It’s not obligated to respond with 200 OK to PUT requests any more than it is obligated to respond so to any other request, is it? If the server doesn’t like where you’re PUTting your stuff, it can simply tell you to 4xx Get Lost.

That doesn’t seem to be the issue.

Rather, I believe HTML has no support for PUT because the verb requires sending a complete document. But how else than by some sort of built-in programming language (à la XSLT maybe) could forms in webpages specify the construction of arbitrarily formed files? In contrast, dealing with POST is trivially easy: the browser builds a list of key-value pairs from the form and hands them to the server. Exactly what happens then – ie., in practice, how a page is constructed from the input – is the server’s business. Which is written in a turning-complete language anyway.

Monday, October 24 2005 at 2:08 AM

Aristotle Pagaltzis said:

Accepted wisdom, I understand, is that you should use POST to create new resources, but PUT to update existing ones, right?

The point about file uploads is good, if not a very compelling use case in itself: all you can do is let the user stick blobs from his filesystem onto the server. It isn’t feasible to parametrise these uploads. Having the option most certainly would have been no harm, though.

Friday, November 18 2005 at 10:11 AM

Aristotle Pagaltzis said:

I know. I was responding your saying that it “might as well expose a POST interface to avoid all of the round trips” – saying that AFAIK, that is considered best practice anyway.

To tie back to the earlier point: PUT can well be used for updating existing resources only, so a server doesn’t have to cede control of its URI space to make PUT useful.

Though, now that I’m thinking about it, there’s no reason that a server couldn’t accept a PUT, but munge the URI to its liking, and send you a redirect to the renamed location on success. So you can even use PUT for resource creation without the server ceding any control over its URI space.

As for parametrised uploads: I meant varying the content of the file that gets uploaded based on user interaction with a form; using PUT for file uploads only precludes that.

Wednesday, November 23 2005 at 11:11 AM

Sandra said:

Wish you luck! google team.

Thursday, July 19 2007 at 8:00 AM