> [[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.]]
True, yet the intended functionality seems to drive the use. Hotlists
and caching seem quite useful for un/parameterized IR tasks but not
interactive tasks. Analysis of 200MB of data might better off if treated
differently than 200MB of paramterized IR query. Similiarly, semi-statefull
connections seem quite applicable to interactive, but not IR tasks. So,
how does paramterized IR differ from interactive - by the existence of
successive state transistions. Most paramterized IR tasks comprise a
single state, whereas interactive tasks usually require that the results
from one state be known in future states.
> 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.
The notion of client refreshes of hotlist items is worrisome wrt POST.
The software performing the refresh has no way of knowing that the
URL resulted from a POST or is just a static document.
For example, when I attempt to retrieve a document that initiated via
a POST request, many forms I tried produce errors or undesired results.
Can POST really be cached or added to a hotlist correctly?
Jim.