Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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
|
