Re: PATCH Draft

DO NOT consider relaxing a requirement for atomicity as the default
behavior. It gives me heartburn to even think about programming a client
against a server that doesn't make atomic updates and fail if the patch
can't be applied. I can't imagine a scenario that corrupted data
wouldn't result and thus the added complexity of providing a modifier to
the request seems like overkill.

Furthermore, 'entire request' is a bit nebulous and would allow use of a
patch data format which had a way to accept a request as complete based on
the rules of the format. The protocol depends on the patch engine to
specify the meaning of complete. If the patch engine says the patch is
complete, the http protocol for atomic complete/fail is satisfied.

But applications based on different patch formats will never be blindsided
by corrupted data.

In terms of not serving an inflight update result, the default must be to
NOT deliver a partially updated resource. While I think there is little
value increasing the complexity to allow a client to authorize an
incompletely updated resource, I can accept that approach.

On Wed, 4 Jul 2007, Mark Baker wrote:

>
> Thanks for reviving this, James.  Here are my comments.
>
> "The server MUST NOT create a new resource with the contents of the
> request body"
>
> Why not?  I don't see the problem.
>
> "The server SHOULD always apply the entire patch atomically and never
> provide (e.g. in response to a GET during this operation) a
> partially-patched body"
>
> I understand the desire for atomicity, but I could see that being a
> feature as long as the fact that any partial response was tagged as
> such (using some future extension).  Suggest removal.
>
> "If the entire delta encoding cannot be successfully applied then the
> server MUST fail the entire request, applying none of the changes"
>
> Why is this needed?  It would seem to depend upon the diff format.
> Plus I could imagine scenarios where it's undesirable (e.g. a streamed
> patch).  Suggest removal.
>
> "Therefore, the client MUST verify that it is applying the delta
> encoding to a known entity by first acquiring the strong ETag [...]"
>
> I don't see why this is required.  Of course, if the client wants the
> guarantees provided by strong etags, it can get them.  But why does
> that matter to a protocol specification?  Suggest removal of that
> paragraph.
>
> Sec 2.1.1 - is this section needed?  The MUST requirements there seem
> to have similar issues to the MUSTs mentioned above.  Suggest removing
> the section.
>
> I suggest the use of 422 instead of 400 in the "malformed delta
> encoding" case of sec 2.2.2.
>
> Sec 2.3 seems to over specify a few things.  For example, the Allow
> response header isn't required to list "all the allowed methods" so
> there's no need for "MUST" there.  I think that all you really need in
> this section is the definition of the Accept-Patch header.
>
> The IANA considerations section should register the Accept-Patch
> header with the header registry defined in RFC 4229.
>
> >   * Should it be possible to create new resources with PATCH
>
> Sure, why not?  HTTP can indicate that with a 201 response.
>
> >   * Should it be required to use If-Match and If-Unmodified-Since
> >     on PATCH.
>
> If that's what the client wants.  But the protocol needn't say
> anything about it IMO.
>
> Mark.
>

Received on Wednesday, 4 July 2007 20:12:55 UTC