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. > 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). best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpWhyJeqsz8K.pgp
Description: PGP signature
