W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: Patch options -- summary of recent conversations

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 12 Aug 2007 15:32:16 +0200
Message-ID: <46BF0BE0.2070502@gmx.de>
To: James M Snell <jasnell@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>

James M Snell wrote:
> Ok, so the recent conversations have been very helpful.  For PATCH it
> appears that we have several options.

James, thanks for the summary.

> One... we could choose to create a new method
> 
>   PATCH /resource HTTP/1.1
>   Content-Type: application/patch
> 
>   {patch format}
> 
> 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.  The most
> interesting of those involve the practicalities of deploying a new HTTP
> method on existing infrastructure.  In theory, it's not supposed to be a
> problem; in reality, unknown methods tend to be blocked by
> intermediaries, making it quite likely that implementors will fall back
> to methods that are known to get through.

The problem is that

a) you will need out-of-band information about the resource; does it 
understand POST with a patch body as expected?

b) it will make it impossible to implement this for a resource that 
already uses POST for something else, such as an AtomPub collection. You 
would need to mint a new URI for accessing the patch semantics. Ugly.

> ...

Best regards, Julian
Received on Sunday, 12 August 2007 13:32:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT