RE: HTTP Methods

Quoting Danny Ayers <danny666@virgilio.it>:

I think the 'blame' for the current bias towards GET
> and POST largely lies with the current generation of browsers, and the view
> of the web as read-only. But this approach to tooling can hardly be blamed,
> as the expectation is heavily aided by HTML forms only including the GET and
> POST methods.

Well, most websites *are* read-only to most people, and this will probably
always be the case. Even if we introduced PUT as a mechanism available with
HTML forms (and *most* use of forms are not PUT operations anyway) this bias
will continue, and should continue. I'm biased towards GET; if something can be
done with GET without doing violence to its semantics then I will.

It isn't a problem of bias, but of *ignorance* of PUT, DELETE etc. on the part
of both developers and tools. People tend not to make the jump from playing
around with text-editors and a tutorial on HTML to actually reading the specs
until they are forced to by situations that can't be kludged around by what
they know. That's natural to a large degree, and it's certainly a big part of
the web's growth that you can get a hell of a lot done by just playing with a
text-editor and an HTML tutorial. The amazing thing is that people are prepared
to take on the mental task of learning about server-side dynamic programming,
heavy-duty client-side javascript and other technologies that work with this
basic HTML/HTTP knowledge and don't see an advantage in the much easier task of
fleshing out their knowledge of the basics (and even in the rather dry RFC
style the HTTP spec is a lot simpler than any programming language).

> I think it's historically interesting that in some areas the range of
> methods is atrophying, while at the same time elsewhere it's being suggested
> that the current range of methods needs to be significantly extended to
> provide adequate handling of resources [1]. It's worth noting that the W3C
> has influence in both directions - in the (X)HTML specs and the Semantic Web
> initiative.

Yes, it strikes me as strange, especially since I remain unconvinced of the case
for MGET. I blame "simplicity", whenever you see groups tearing away from the
currently agreed core you normally find that they are both taking their
position on the grounds of "simplicity". The problem is simplicity is
complicated, because it relates more to psychology than technology and there
are a variety of cues that will influence which choice a given developer will
see as simpler.
In addition simplicity can only be reliably measured after the fact; often an
attempt towards greater simplicity brings in unforeseen edge-cases that must be
either dealt with, or left as problems, and the effect is an increase in
complexity for any reasonably resilient implimentation.

Premature simplicity is the root of all evil.
(Apologies to Knuth).

-- 
Jon Hanna
<http://www.hackcraft.net/>
*Thought provoking quote goes here*

Received on Wednesday, 25 February 2004 05:40:14 UTC