You don't change anything in thw webor anywhere else
You don't commit yourself to anything (except cost of access)
You always get the same logical resulf for the same URL
These are really useful design criteria which allow one to
make important deductions. As an arbitrary example, you can
Cache the result of a GET
Preemtively look-up the result of a GET on behalf of someone
I said logical above because things like "the state of the coffee
pot" is a time-dependent thing though always logically the same.
So if the function returned by the form, such as
"A critique of the syntax of (xxx) as anHTML document"
can be regarded as an idempotent function, which it can,
then GET is appropriate.
[[There is a snag when the parameters (like an HTML document
as a litteral string) get too big to hold in a URL.
But then, it is not so obvious that you want the same
things to happen to it anyway (caching, saving in
hotlists). We wouldn't want someone saving the results
of an analysis of 200MB of astrophysics to a hotlist
to be storing the 200MB away, for example.]]
If however the function has side-effects, like
"the result of my ordering a pizza with pepperoni",
then it should *not* use get, as clearly screwups could
occur. For example, suppose the pizza hut returns a
useful calendar and menu acknowledging each order, and you put
one in your hotlist. And every day your client refreshes
cached copies of everything in your hotlist... this
could affect your health.
POST is appropriate here.
Tim
____________________________________________________________
Tim Berners-Lee Director, W3 Consortium
MIT Laboratory for Computer Science Phone +1 (617) 253 9670
545 Technology Square Fax +1 (617) 258 8682
Cambridge MA 02139, USA Email timbl@w3.org