Re: Idempotent partial updates

On 28.02.2012 04:54, 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"?

This is a side-track argument anyway. To work with partials PUT also 
requires If-Match. Without it PUT becomes non-idempotent and one might 
as well use PATCH.

That side effect is not very visible in the 2616 wording. In the new 
HTTPbis wording there is no choice of getting it wrong, they need to use 
PATCH.

>
>> 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.
>

Yes.

>>>> - 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.

In order to work reliably for partials PUT requires If-Match and 
*additionally* needs some header mechanism to determine the difference 
between full and partial replacement (Range, Content-Type, etc).

In short its *more* complex to use PUT than PATCH.

/2c

AYJ

Received on Tuesday, 28 February 2012 01:19:41 UTC