Re: Idempotent partial updates

I wasn't talking so much about partial updates using PUT, but the 
general reliance on the concept of idempotence at all.

Various features in HTTP, such as pipelining, recovering from closes etc 
rely on certain methods being idempotent.  I would propose one can never 
assume any method is idempotent, since that is up to server-side 
implementation.

Whether in practise PUT is usually actually idempotent or not I don't 
have any information.

But my feeling is there is a disconnect between HTTP and those making 
websites in this regard.

On 28/02/2012 1:40 p.m., James M Snell wrote:
>
> The possible idempotency of a partial update depends entirely on the 
> nature of the resource being updated, not the method used. At the http 
> level, a partial update can never be assumed to be idempotent, even if 
> that's how it's implemented in one specific case. The semantics of put 
> are clear in that it always must be considered to be idempotent.
>
> On Feb 27, 2012 4:30 PM, "Adrien de Croy" <adrien@qbik.com 
> <mailto:adrien@qbik.com>> wrote:
>
>
>     I've always had an issue with this concept of "Idempotence".  I
>     really wonder whether it actually exists in the real web.
>
>     Many servers can and do have side effects for any particular method.
>
>     So one cannot claim that any method is in fact Idempotent?  Not in
>     all cases anyway.  One could write a script for which POST was
>     idempotent.  Likewise there are plenty of URIs where GET is not.
>
>     I think the concept is not well understood in the web authoring
>     space, and no-one really takes much care to make website
>     implementations honour the intent of HTTP wrt methods which are
>     supposed to be Idempotent.
>
>     My point is, why persist with this language?
>
>     Adrien
>
>     On 28/02/2012 4:54 a.m., Julian Reschke wrote:
>
>         On 2012-02-27 16:35, Mike Kelly wrote:
>
>             ...
>
>                 I don't think it ever was ambiguous.
>
>                 "The PUT method requests that the enclosed entity be
>                 stored under the
>                 supplied Request-URI."
>
>
>             It was ambiguous enough to lead to real-world
>             implementations which
>             directly violate it. You've said as much above, and the
>             action to
>             ammend the semantics
>             ...
>
>
>         Just because implementations get something wrong doesn't mean
>         the spec was ambiguous; witness all the sites that did/do
>         destructive things on GET, that do not implement HEAD, etc.
>
>                 I don't think it's an over-specification. And even if
>                 it was, it's not new.
>
>
>             It is now explicit and non-ambiguous (i.e. prevented).
>             That is new.
>
>             This is getting away from the real intention of the
>             question: what are
>             your thoughts on the benefits of partial prevention vs
>             non-prevention?
>
>
>         You could ask the same question for most methods; PUT means
>         "store" and always has. There's no good reason to change that
>         (allowing partial updates would be a change).
>
>                     - Is it acknowledged that this change will
>                     effectively prevent proper
>                     idempotent partial updates on the web?
>
>
>
>                 No. You can do idempotent partial updates with POST
>                 and PATCH (by including
>                 an If-Match header field).
>
>
>             I'm aware of this technique. It's neat, but I wouldn't
>             consider it
>             explicitly idempotent; i.e. it's idempotent nature is not
>             explicit and
>             is therefore not very visible. This is an issue for
>             intermediary
>
>
>         How is is "not visible"?
>
>             components, such as HTTP client libraries in mobiles which
>             (if the
>             request were PUT) could handle the re-issue of failed
>             requests. Afaik,
>             this infrastructure already exists  right now on the web
>             and works
>             fine for partial PUT requests.
>
>
>         Then I believe the right thing is to request changes to these
>         libraries so that they handle PATCH (for instance) better.
>
>                     - In light of the recent proliferation of 'mobile
>                     clients' which
>                     operate on relatively slow and unreliable networks
>                     where partial
>                     idempotent updates would be ideal; is the loss of
>                     idempotent partial
>                     updates considered acceptable?
>
>
>
>                 See above: (1) PUT never allowed partial updates, and
>                 (2) you don't need PUT
>                 to make modifications idempotent.
>
>
>             as above:
>
>             (1) Then why were the semantics amended, and why would
>             others have
>             implemented against the spec in that fashion?
>
>             (2) You need PUT to make a request that is visibly
>             idempotent through
>             the network.
>
>
>         Yes, see above.
>
>         I think it's pretty clear that I won't convince you (the
>         discussion happened before on rest-discuss I believe), and you
>         won't convince me, so I'd be interested to hear other people's
>         opinions.
>
>         Best regards, Julian
>
>
>     -- 
>     Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
>     WinGate 7 is released! - http://www.wingate.com/getlatest/
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/