Re: Idempotent partial updates

On Tue, Feb 28, 2012 at 8:37 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2012-02-28 05:28, Martin Thomson wrote:
>>
>> I think that the "problem" in this case is one of invention only.  If
>> you desire the ability to do a partial update of a resource, then you
>> probably don't have enough resources.  I know that's a gross
>> generalization, but I haven't seen that comment in the thread.
>>
>> I agree with Mike that PATCH (or a special POST) aren't visibly
>> idempotent, which is a crucial characteristic if this is going to
>> work.
>
>
> How exactly is it "not visible"?
>
> From <http://greenbytes.de/tech/webdav/rfc5789.html#rfc.section.2.p.4>:
>
> "A PATCH request can be issued in such a way as to be idempotent, which also
> helps prevent bad outcomes from collisions between two PATCH requests on the
> same resource in a similar time frame. Collisions from multiple PATCH
> requests may be more dangerous than PUT collisions because some patch
> formats need to operate from a known base-point or else they will corrupt
> the resource. Clients using this kind of patch application SHOULD use a
> conditional request such that the request will fail if the resource has been
> updated since the client last accessed the resource. For example, the client
> can use a strong ETag [RFC2616] in an If-Match header on the PATCH request."

The amount of infrastructure that exists right now, or in the near
future, which understands and is built to leverage idempotent PATCH is
tiny in comparison to PUT. Visibility, in practice, depends on the
relative ubiquity of the semantic, and not just on whether a
spec-which-says-so makes it through to RFC.

So, from a purely theoretical stand-point you may be right, but in the
real-world I don't think their visibility is even close to equivalent.

Cheers,
Mike

Received on Tuesday, 28 February 2012 10:23:35 UTC