Re: Patch options -- summary of recent conversations

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 UTC