Re: Feedback on ISSUE 27 (PUT idempotency)

ons 2007-01-03 klockan 11:08 +0100 skrev Julian Reschke:
> (see <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i27>)
> 
> This topic was just discussed over on rest-discuss, and I think the 
> recommendation is to relax/rephrase the definition of idempotency.
> 
> See: <http://tech.groups.yahoo.com/group/rest-discuss/message/7387>

Hmm.. PUT indeed is a odd beast in this discussion. 2616 in this quite
clearly does not consider much servers using revision control or similar
where each executed PUT has irreversible and unique sideeffects (i.e.
new revision created), only focusing on blind store of PUT entities.

It can be argued that such applications of HTTP should also use
'If-Match: "OldEtag"' on update, and 'If-None-Match: *' on create to
guard themselves if those side-effects is important to the application.
But this scheme fails is the server application can not use strong
ETag:s.

It's unfortunately hard to get this down into good writing, as to many
applications those side-effects is of no importance at all. I.e.
consider a revision controlled server used as dumb file storage by the
clients. To the clients the PUT requests is probably idempotent as it
does not matter that multiple revisions of the same content got created
on the server so adding restrictions on when PUT is idempotent based on
conditionals like above is not quite appropriate.

Maybe rewriting 9.1.2 to read "the <ins>significant</ins> side-effects
of N > 0 ..." would do? Leaving it up to each application to define
whats 'significant'.

Regards
Henrik