Re: Idempotent methods, HTTP PUT, and app:edited

["Mark Baker" <distobj@xxxxxxx>]

I don't quite follow, but idempotence just means that the effect of N
messages is the same as 1.  "Side-effect free" is otherwise known as
"safe", and while all safe interactions are idempotent, not all
idempotent interactions are safe ... like PUT for example.

On 11/15/06, Nikunj Mehta <nikunj.mehta@xxxxxxxxxx> wrote:
> Has anyone pondered the idempotence of a PUT method on an APP member
> resource?
>
> If you attempt to PUT repeatedly, then the first one that succeeds will
> set a new ETag expectation. Subsequently, if PUT requests with
> "if-match" preconditions are made, these would fail thus saving the
> idempotence requirement on PUT (RFC 2616, 9.1.2). OTOH, without
> preconditions, we have to store the new entity and change the app:edited
> element. IMHO, That creates a "side-effect", and hence is not an
> idempotent operation.
>
> Nikunj