At Wed, 18 Jul 2007 17:48:03 -0700, "John D. Mitchell" <[EMAIL PROTECTED]> wrote: > The RFC is clear in separating out which methods are safe and > idempotent from those that are only idempotent from those that are > neither.
Sorry, I was confused. You said: > If it has such side effects then it is, by definition, not > idempotent. I wasn’t sure which side effects you were referring to. I referred to side effects in a functional programming language. I was thinking of server side state changes. Obviously, as you say, some methods have side effects (that is, are not ‘safe’) but are idempotent. To be clear, all safe methods are ipso facto idempotent. Some methods are not safe but nonetheless are declared idempotent. Some are, as you say, neither. > DELETE, for example, "must" be idempotent. Agreed. > PUT is also "must be" idempotent precisely because multiple puts of > the same stuff to the same place gives the same results. Again, to be clear, and I believe this is the crux of our disagreement: 9.1.2. | Methods can also have the property of “idempotence” in that (aside | from error or expiration issues) the side-effects of N > 0 identical | requests is the same as for a single request. This means side effects, server state changes, not response bodies or response status codes. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpiSx2r3jiA8.pgp
Description: PGP signature
