Re: Patch options -- summary of recent conversations

On Aug 10, 2007, at 10:00 AM, James M Snell 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}

If the server advertises its support for this Content-Type somewhere,  
I could imagine this being sufficiently reliable.  I'm still a little  
worried that the server might respond successfully to a POST request  
without treating it as the client desires -- e.g. adding the request  
entity to an Atom collection, submitting it to a HTTP "drop-box",  
treating it as an alternative body for the resource, or one of the  
many things POST might already be used for out there.

I still prefer PATCH as a verb.

>
> Second... there's the question of how to return a representation of  
> the
> modified resource.
>
> The first option is to use 200 OK with the Content-Location header.
>
>   HTTP/1.1 200 OK
>   Content-Location: /resource
>   Content-Type: text/plain
>
>   {foo}
>
> At issue is whether or not this is unambiguous enough to work and
> whether or not Content-Location will work effectively (Roy pointed out
> the issues with reconstructing Content-Location when intermediaries  
> are
> involved).

Don't forget, there's also Content-MD5.  That could be used for the  
client to check whether the patched resource is exactly what the  
client would have gotten with a local application of the delta, or  
whether the server did some post-PATCH content mods (reformatting  
XML, adding metadata inside resource, etc).

Lisa