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.
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.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf