Re: Some comments on the PATCH draft

After watching the conversation on this particular issue, I think the
only reliable solution is to add a statement like the following*:

   When a PATCH request is sent to a Request-URI that is capable of
   returning multiple alternate representations of a resource, the
   enclosed entity SHOULD contain sufficient information to allow the
   server to determine the representation to which the requested changes
   are to be applied.  If the server desires that the request be applied
   to a different URI, it MUST send a 301 (Moved Permanently) response;
   the user  agent MAY then make its own decision regarding whether or
   not to redirect the request.

In other words, the delta encoding** is responsible for identifying the
representation that is being modified.

* Note that some of this text was lifted from RFC2616
** or whatever we ultimately end up calling it

- James

Andreas Sewe wrote:
> James Snell, the author of the recently revived PATH draft, has asked me
> to resend my comments for further discussion to this list. (Originially
> I send my comments to James only.)
> 
> So here they are:
>> What bothers me currently about the PATCH draft is that it refers
>> to resources throughout even though what is actually patched is a
>> *representation* of a resource.
>>
>> Besides being an issue of terminology this also has some
>> implications when content negotiation is used. Granted, content
>> negotiation complicates things quite a bit and might not be
>> needed in most cases, but since PUT works fine even for
>> negotiated resources I have the feeling that PATCH should work,
>> too.
>>
>> The problem with the draft is, however, that the content type of
>> the entity send cannot be determined, since the Content-Type
>> header contains (rightly so!) application/diff or some such type.
>> But the assumption that the base media type is that of the
>> resource is false as soon as that resource has many different
>> representations. Which representation should the diff be applied
>> to?
>>
>> Representations might differ by Content-Type, Content-Language,
>> etc., information which can be found in the Vary header. But
>> besides Content-Type the other headers can be provided directly;
>> only Content-Type carries the diff format's media type.
>>
>> Unfortunately, I can't think of a clean solution of the top of my
>> head; both adding a header like Patched-Type and requiring a
>> media type parameter like application/diff;type="text/plain" seem
>> clumsy to me. But if PUT works with content negotiation, so
>> should PATCH!
>>
>> Regards,
>>
>> Andreas
> 
>

Received on Thursday, 5 July 2007 19:28:03 UTC