Basically, I concur with Adam so I'm just going to respond to a couple of nits...
On 7/17/07, Erik Hetzner <[EMAIL PROTECTED]> wrote:
At Tue, 17 Jul 2007 17:57:16 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > > I read this as 'side effect', like a side effect in functional > > programming. I tend to agree that it would be good if you got then > > same response, but the constraint is that you simply get the same side > > effects, not the same actual response. OPTIONS, for instance, should > > not have side effects, but it has a response. > > If it has such side effects then it is, by definition, not idempotent. Huh? What such side effects? PUT obviously has side effects. Methods without side effects are safe, and by definition idempotent. Methods with side effects might or might not be idempotent.
The RFC is clear in separating out which methods are safe and idempotent from those that are only idempotent from those that are neither. DELETE, for example, "must" be idempotent. PUT is also "must be" idempotent precisely because multiple puts of the same stuff to the same place gives the same results.
> In practice, some people share the view that it's okay to stretch the > definition to be looser. > > Personally, I've done it both ways since it was convenient to have > some extra information in the response and/or status code. I just > didn't kid myself that the "function" was actually idempotent in those > cases and the only consumers of those resources were programs that, in > essence, I controlled. From the Rest wiki: <http://rest.blueoxen.net/cgi-bin/wiki.pl?RestFaq#nid1VU> […] 'idempotent' means repeating the operation ends up with the resource in the same state (it doesn't mean all the responses are always identical).
Indeed, as noted, some people have a looser view and try to justify continuing the use of the term idempotent. I'm open to the loosening of the practice but not to the hijacking of the definition. Take care, John
