Subject: PATCH draft

From: James M Snell <[email-masked]>
Date: Thu, 12 Jul 2007 09:11:34 -0700

Just a general FYI... I have prepared another update to the PATCH draft
based on the feedback discussed here on the list.  It did not get sent
off in time for the cutoff so it likely will not post until sometime
after the 23rd.  Until it does publish, I wanted to at least give a
heads up that a new draft was coming.

Some of the changes that have been applied include:

  * Terminology change from "delta encoding" to "patch document"

  * Added clarification on the safety and idempotency of PATCH

  * PATCH responses are not cacheable "unless the response includes
    appropriate Cache-Control or Expires header fields"

  * 200 responses MUST include a representation of the modified
    resource. 204 responses are used to indicate successful response
    without returning a representation.

  * Suggest using 422 Unprocessable Entity to indicate that a properly
    formatted patch document cannot be processed

  * Clarify the use of 412 and 409 to indicate concurrent and
    conflicting resource modifications.

  * Added registration for the Accept-Patch header.

  * Relaxed the requirements for the use of If-Match and If-Unmodified-
    Since.

  * Add language that clarifies the difference between PUT and PATCH.

  * Remove the restriction against creating new resources with PATCH

  * Add language that clarifies the issues with PATCH and Content
    Negotiation.

  * Use of Accept-Patch on any response implies that PATCH is supported.

  * Add language advising caution when pipelining PATCH requests.

- James

p.s. I cross posted this to two mailing lists. My apologies to those of
you who receive multiple copies.

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 16 Jul 2007 17:59:09 -0400

(removed atom-protocol)

>     without returning a representation.

Please don't do that.  If a server wants to return a representation of
the modified resource, it can do so and signal it (Content-Location).
Requiring any particular response prevents it from being used for
other things.

It also seems a bit odd considering that the intent of PATCH is - like
PUT - to set the state of the resource explicitly, so in general,
after a successful response the client pretty much knows the state and
so the representation is probably not communicating much.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

---

From: James M Snell <[email-masked]>
Date: Mon, 16 Jul 2007 15:06:09 -0700

> Requiring any particular response prevents it from being used for

The goal is to allow for an unambiguous response.  If the use of the
Content-Location header in the response would be enough to eliminate any
ambiguity, then I'm fine with that.

> so the representation is probably not communicating much.

For a byte or character based patch, this is likely true.  For a
structural patch (e.g. adding an XML attribute) on something like an
Atompub collection, it's not so straightforward.  The semantics of a
particular patch format and the specific implementation may allow a
server to apply a patch in a not-entirely-deterministic way.

- James