Julian,
On 2009-11-13 23:35, Julian Reschke wrote:
> Brian E Carpenter wrote:
>> On 2009-11-13 20:19, Julian Reschke wrote:
>>> Brian E Carpenter wrote:
>>>> As far as I can tell, the proposal places the burden for ensuring
>>>> atomicity entirely on the server. However, PATCH is explicitly not
>>>> idempotent. If a client issues a PATCH, and the server executes the
>>>> PATCH,
>>>> but the client then fails to receive an indication of success due to
>>>> an extraneous network glitch (and TCP reset?), then what prevents the
>>>> client
>>>> issuing the same PATCH again? In other words, absent a two-phase
>>>> commit,
>>>> there appears to be no transactional integrity.
>>> How is this different from PUT or POST? If you need repeatability of the
>>> request, just make the request conditional using "if-match"...
>>
>> PATCH seems more dangerous than those simply because it is partial
>> update of a resource, and I don't feel it's sufficient to say that
>> there might be a way of detecting that it has failed to complete,
>> if you're executing a series of patches that build on one another.
>
> POST can be a partial update as well, for the simple reason that POST
> can be *anything*. As a matter of fact, people are using POST right now,
> as PATCH was removed in RFC 2616.
I wasn't involved in reviewing RFC2616 (or in the original design of POST,
even though it happened about 20 metres from my office at that time). But
yes, POST also lacks transactional integrity. Incidentally, that recently
caused me to donate twice as much as I intended to the relief fund for
the tsunami in Samoa, although the direct cause was a network glitch.
>> Talking about transactional integrity in the IETF has always been
>> hard, for some reason. But something described as "patch" is exactly
>> where you need it, IMHO.
>
> PATCH does not need to be special, and shouldn't be special. That being
> said, it wouldn't hurt to clarify that PATCH can be made repeatable
> (idempotent) by making it conditional.
I would make that a SHOULD and, as I said originally, be more precise
about how to use strong ETags to achieve it.
Brian
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf