Re: Method for A? (fwd)

>I have never seen any need for POST on A.  POST is only needed when
>sending volumes of data to a server, which only results from FORM
>submissions.  I have never in 5 years of working on the web seen any
>need for POST associated with A.

This is at least the second, if not the third, time this thread has
started in my three years on this list -- so I guess someone sees the
need for this type of functionality.  In my four years of working
on the web I've wished for this sort of functionality at least two
or three times.  The main argument I see for something along the
lines of an A with a method of post is hiding ugly URLs with query
strings for the parameters to a get request.  The second compelling
argument I've heard is actually to accomplish the equivalent of a
form submission without the widgets usually accomanying a form.
This makes sense in the case where the data would have been stored
in hidden fields with no need for user input.  This would make the
submission look like any other link.

Now that I've laid out those arguments I'll mention that I don't
agree with either of them.  For the latter I assume using the form
element button with CSS formatting could accomplish that goal.  The
former I've just decided is empty.  It's too bad that URLs for a
GET request with arguments look ugly since they serve a very valid
purpose of mapping the URL to an explicit set of output in the way
that a post URL that ends with the script name does not.  This lets
users bookmark the resulting page and share it in any number of
other ways without describing the entire process of getting to the
right place and entering the right arguments.  These arguments made
me a convert to get and I know choose post only when my apps require
context be preserved.

That said, I'm shocked at the argumentative responses to this
thread.  The original post was well reasoned and exhibited a grasp
of the issues that your average "why can't we have <page>"-type
feature suggestion never attains, yet the first couple of responses
I received treated it the same way.  I'm all for containing the
"tag soup" that HTML could (has?) become; I'm all for educating
others about the visions the W3C has for HTML; I'm even for telling
people there ideas just don't cut it.  But let's get real -- this
guy offered up and idea, talked about some experiences with it,
discussed the implications it would have for current practice, and
decided to share his ideas.  For that he got flamed.  It's a shame.

Chuck

--
Chuck D'Antonio
Programmer & Network Support Specialist
FAS Administrative Computing
Harvard University

Received on Thursday, 25 September 1997 15:37:46 UTC