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