Re: HTTP Patch proposal

On Tue, Apr 27, 2004 at 11:43:34AM +0100, Graham Klyne wrote:
> I don't think this poses any fundamental problems for Web architecture, but 
> the only reason I can see for not using POST is this:
> [[
>    The PATCH request is subject to access control, which in turn may
>    require authentication.  The PATCH request SHOULD be subject to the
>    same access control permissions as the PUT request.
> ]]

I wouldn't personally use POST, because the semantics of PATCH seem to
be very similar to PUT.  i.e. the client has direct visibility into the
terminal state of the resource, even in part.

FWIW, I've come close a couple of times (though I never actually needed
to, in the end) to doing something like PATCH using RFC 3229, "Delta
encoding in HTTP".  While targetted at delta updates via GET, it says
this;

     Nothing in this specification specifically precludes the use of
     a delta encoding for the body of a PUT request.  However, no
     mechanism currently exists for the client to discover if the
     server can interpret such messages, and so we do not attempt to
     specify how they might be used.

Which makes sense; HTTP's lack of support for mandatory extensions makes
deploying these kinds of extensions difficult.  So the options seem to
be;

- PATCH
- M-PUT (RFC 2774) + RFC 3229
- a PUT binding for SOAP + RFC 3229

FWIW, if there was anything for the TAG to consider here, it might be to
document some best practices for deploying various forms of HTTP
extensions and to help protocol developers understand the tradeoffs.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Tuesday, 27 April 2004 10:38:24 UTC