Re: Idempotent partial updates

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

Received on Monday, 27 February 2012 15:55:21 UTC