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

[Nikunj Mehta <nikunj.mehta@xxxxxxxxxx>]

Mark Baker wrote:
> I don't quite follow, but idempotence just means that the effect of N
> messages is the same as 1.  
Exactly the point. When you see N different PUT requests, each produces 
a different app:edited (and hence a different ETag) value in the member 
entity. Doesn't that make this behavior *not* idempotent?
> "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.
This is besides my point. I did not ask for PUT to be side-effect-free.
> 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