[
Lists Home |
Date Index |
Thread Index
]
> That code CAN have side effects. It is not REQUIRED to have side
> effects. And never-the-less, the HTTP specification does NOT deal with
> side-effects. It is more subtle than that. Look at RFC 2616 yourself:
>
[...]
> I think you mean "POST", not "PUT". Even so amended, I disagree. Good
> web system designers know that in order to make a resource something
> that can be linked to or bookmarked, they must use GET. For instance any
> online discussion forum (e.g. slashdot) serves up discussion pages
> through GET, not POST. Similarly, most online catalogs use individual
> GET-table URIs for each item, even though the pages are dynamically
> generated from a database.
>
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.
I don't see where the idempotence of GET enters into it.
Did I miss something?
Ramin
|
