Re: Idempotent partial updates

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/

Received on Tuesday, 28 February 2012 00:28:52 UTC