Re: Patch options -- summary of recent conversations

On fre, 2007-08-10 at 10:00 -0700, James M Snell wrote:

> Second... there's the question of how to return a representation of the
> modified resource.

You CAN say that 200 OK always do that for PATCH. Does not really need a
new response type for PATCH.

The trouble only arises if you want the method to be able to selectively
return the new representation OR a successful status message entity
regarding the patch operation.


> 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

This discussion was more oriented towards POST than PATCH imho, trying
to find a rule where a 200 OK response entity could always be identified
as the requested respource regardless of the method involved, which is
not the case for POST where 200 OK may be just a informal status
message, or the modified entity, with no good indication of which is
being returned.

> 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).

Content-Location is an issue when there is reverse proxies involved
rewriting the requested URI before it's sent to the web server, making
the web server unaware of it's real URL.

Personally I would recommend nearly always returning 204 with a cache
validator allowing the client to request the resulting resource if it
wants it. I don't see much benefit in complicating the specification by
a conditional return of the modified resource when the same task can be
acheived by a followup method, and quite safely so thanks to cache
validators.

Regards
Henrik