Joe Gregorio
Bill de hÓra points out one of my biggest annoyances with HTML, that it doesn't support a larger complement of HTTP verbs. He does have a different spin on it than I had previously thought of, that because it only supports GET and POST that HTML effectively subsets HTTP.
So, HTML subsets HTTP. If any other technology did that, there'd be uproar. Yet I don't think the W3C Technical Architecture Group have even discussed this. Why does it break web architecture? Well, instead of using PUT/POST/DELETE in a form against a single resource/URI, I either have to use multiple URIS to operate on a single resource, or I have to tunnel the PUT/DELETE actions though the entity. Truly, deeply, absymal.
It certainly is annoying, and this is the kind of thing I'd much rather see the W3C HTML working group work rather than creating non-backward compatible versions of XHTML.
XForms adds PUT.
A server can also support DELETE on a URI even if XForms can't send it.
Posted by Ken MacLeod on 2003-08-01
That makes XForms that much more frustrating. They had a chance to fix real problems and instead wandered off into the weeds with a new event model and data mapping architecture.
Posted by Joe on 2003-08-01
How is this a real problem? I can understand why it's theoretically inelegant, but I can't imagine a situation in which I'd ever have actually wanted to use PUT or DELETE. (I regard Mr. Vitiello's proposed uses as an abomination against all that is proper.)
And while I don't know how useful XForms is going to be, once it's out in the wild, I do have to nod approvingly at most of the changes that they've made -- I'd go so far as to say that PUT is only useful in XForms because of the data model changes. (It makes sense to PUT an XML document at a URI; it makes minimal sense to PUT a collection of variables at a URI.)
Posted by Mike Kozlowski on 2003-08-01
How would this sound if we changed PUT and DELETE to something say more concrete?
How is not having a SPOON or a KNIFE a real problem? I can understand why it's theoretically inelegant, like say eating soup or maybe a steak, but I can't imagine a situation in which I'd ever have actually wanted to use a SPOON or a KNIFE, since I only tend to eat spaghetti, and even then I can cut the meatballs with the edge of the FORK, which is enough KNIFE-like behaviour for me. (I regard Mr. Vitiello's proposed uses as an abomination against all that is proper etiquette.)
Posted by Joe on 2003-08-01
Given a spork, all else is optional...
Seriously, though, in which situations would you want to use PUT and DELETE? The only time that would seem to make any sense is in a CMS. And even there, you generally want to do enough pre-processing and validation that POST seems as logical as PUT or DELETE.
To extend your analogy past the point of all usefulness, wishing for PUT and DELETE in HTML sounds to me like wishing for a crescent wrench and hammer in your silverware drawer -- they're useful tools, but not particularly helpful in this context.
Posted by Mike Kozlowski on 2003-08-02
Mike writes, "enough pre-processing and validation that POST seems as logical as PUT or DELETE."
There's a very basic misunderstanding here that "POST means processing; GET, PUT, and DELETE mean no processing."
GET, PUT, DELETE and POST (et al) are all unique actions that can be performed on a resource, regardless of whether processing is performed on the way through.
Posted by Ken MacLeod on 2003-08-02
An extension of HTML to support the full set of verbs and to support posting text/xml in addition in to x-www-form-url-encoded and I could write HTML clients for the AtomAPI, RESTLog, and CommentAPI
Posted by Joe on 2003-08-02
Ken: Fair enough. I suppose what I was getting at is that, as a practical matter, in most of the setups I've worked on, it's easier to use processing logic if the request is always going to a single processing URL than if it's going to arbitrary destination URLs.
Joe: That's a useful example. Thanks.
Posted by Mike Kozlowski on 2003-08-03
Mike, just so it's clear, most weblog implementations will still have only one single processing module or CGI for all of the URLs. For them, they are passed the HTTP method and relative URL as parameters.
See Joe's earlier Carrot Versus Orange entry.
Posted by Ken MacLeod on 2003-08-03
Posted by Eric Vitiello on 2003-08-01