[
Lists Home |
Date Index |
Thread Index
]
Ramin Firoozye wrote:
>
>...
>
> Thank you for the correction. Of course, I meant POST.
>
> I thought the whole point of this thread was the side-effects and their
> relation to the spec. As has been mentioned elsewhere, most server-side
> toolkits remove the distinction between GET and POST so to the server-side
> code jockey, the parameters just appear as a bunch of key/value pairs.
> Along with the bookmarking issue, the choice for an app-builder becomes:
>
> - Use GET when you want the user to invoke this servlet/function/ASP/etc
> directly (i.e. via a link or bookmark) AND parameters to be passed can
> fit on a URL.
>
> - Use POST when you want to force the user to start at a given point AND
> parameters are large or there is an attachment involved.
Right, but safety (in the HTTP sense) will often drive this decision.
If "jumping in directly" will send a message to the supplier to "buy
this item" or "invoke self-destruct sequence" then you will NOT use GET.
You don't want somebody finding a link in an email or log and invoking
the service by clicking it. And you don't want some kind of spider (e.g.
Google's) to do so.
On the other hand, if its okay for the link to be run over by Google
once a month with no serious problems then you can use GET and get the
benefits of Google's indexing and caching. i.e. usually for idempotent
operations you will naturally use GET because that gives you the best
mix of features.
Paul Prescod
|
