[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: idempotent POSTs

• To: <xml-dev@l...>
• Subject: RE: idempotent POSTs
• From: "Ramin Firoozye" <ramin@w...>
• Date: Thu, 25 Apr 2002 15:33:30 -0700
• Importance: Normal
• In-reply-to: <3CC87D25.3249AD92@p...>

> 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

• Follow-Ups:
  • Re: idempotent POSTs
    • From: Paul Prescod <paul@p...>

• References:
  • Re: idempotent POSTs
    • From: Paul Prescod <paul@p...>

• Prev by Date: RE: Future of Databases
• Next by Date: SOAP and the Web
• Previous by thread: Re: idempotent POSTs
• Next by thread: Re: idempotent POSTs
• Index(es):
  • Date
  • Thread