[
Lists Home |
Date Index |
Thread Index
]
On Thu, 31 Jul 2003, John Cowan wrote:
> Norman Walsh scripsit:
>
> > What if the GET drops a can of coke on your desk?
>
> Short of matter replication (Star Trek or Drexler varieties), it can't do
> that. If the can is brought from somewhere else, that's a side effect,
> and GETs have to be idempotent and therefore side-effect-free.
As long as when you repeat the GET it delivers another can of coke to your
desk from somewhere else - it _is_ idempotent. It is the _repeatability_
that is key, not whether it initiates a side-effect. Side-effect free
requests are idempotent, but not all idempotent requests are side-effect
free.
I quote from RFC 2616:
" 9.1.2 Idempotent Methods
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. The methods GET, HEAD, PUT and
DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD
NOT have side effects, and so are inherently idempotent.
However, it is possible that a sequence of several requests is non-
idempotent, even if all of the methods executed in that sequence are
idempotent. (A sequence is idempotent if a single execution of the
entire sequence always yields a result that is not changed by a
reexecution of all, or part, of that sequence.) For example, a sequence
is non-idempotent if its result depends on a value that is later
modified in the same sequence.
A sequence that never has side effects is idempotent, by definition
(provided that no concurrent operations are being executed on the same
set of resources).
"
--
Benjamin Franz
People buy holes, not drill bits.
---Peter Deutsch
|
