Re: Patch options -- summary of recent conversations

On 8/10/07, James M Snell <jasnell@gmail.com> wrote:
> Or... since patch formats are identified by mime media type, it would be
> possible to use POST and allow the server to derive the intention of the
> request from the media type.
>
>  POST /resource HTTP/1.1
>  Content-Type: application/patch
>
>  {patch format}
>
> Valid arguments can be made for or against either approach.

I don't recall much of a discussion about using POST, but IMO it would
be inappropriate because POST provides no visibility into the ultimate
state of the targetted resource, whereas the action of "patching" a
resource requires it.

> The options discussed have been to use either the Expect header or to
> define a new Prefer header.
>
>  Expect: 209-content-returned
>  Expect: 204-no-content
>  Prefer: 209-content-returned
>  Prefer: 204-no-content

I'd prefer the Prefer values not include the response code itself,
because other response codes may be used.  For example, a response to
a "Prefer: 209-content-returned" could be a 200 with Content-Location
if that's how the server wants to meet the preference.  Also, in the
future, other response codes might be defined which have a similar
meaning, and we don't want to prevent servers from using those.

> If we do end up going with the 209 status code and Prefer header, would
> it make the most sense to separate those out into separate I-D's? Or
> would people be comfortable with bundling those in with the PATCH draft?
>  I'm fine with either.

I assume it would be less work to bundle them, so that would be my preference.

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

Received on Friday, 10 August 2007 19:24:56 UTC