Roy,
Just a couple more comments below, and then I will have
said all I can usefully say.
On 2009-11-14 12:57, Roy T. Fielding wrote:
> On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
>> 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.
>
> That doesn't have anything to do with POST lacking transactions.
> Any server is fully capable of detecting repeated transactions
> just by looking at the data sent.
Not in this case. The service was instantiated once, received
a legitimate series of POSTs, including the final one triggered
by a SUBMIT button, and then the final response code to the client
(a standard browser) vanished, for whatever reason. [Digression
about why this failure was probably caused by a NAT deleted.]
The human client simply sees a browser timeout and has no possible
way of knowing whether the SUBMIT executed. As it turns out, my credit
card bill later showed that it did.
>>>> 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.
>
> No. The patch format may be designed to be repeatable (append).
> The patch format may include its own conditions (context diffs,
> before/after metadata, etc.). HTTP is neither a filesystem nor
> a database, so don't expect the protocol to interfere with
> legitimate communication just because some resources might
> require transactions for tightly-coupled behavior. That is not
> the protocol's job.
Given that HTTP took the stateless approach that it did,
I don't expect the protocol to embed transactional integrity.
But I do expect the protocol spec to describe in normative terms
how to detect a relatively likely type of failure. I agree
that whether that is needed depends on the use case for PATCH.
Brian
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf