Re: Idempotent partial updates

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> 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/<http://www.wingate.com/getlatest/>
>
>
>