Re: Some comments on the PATCH draft

Roy T. Fielding wrote:
> Andreas Sewe wrote:
>>> 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?
> 
> Negotiable content URIs don't normally support PUT either, for
> good reasons.  Authoring should be done on source resources, not
> resources that are derived from other sources.
> 
> PUT doesn't work with content negotiation.

IMHO there's nothing in RFC 2616 that would prevent PUT from working
with negotiated resources.

Say, the resource <http://example.org/image> has both "application/gif"
and "application/png" representations. If I PUT an image of type
"application/png" at the above URL, the server has two options which
both satisfy the semantics of PUT:

# If the Request-URI refers to an already existing resource, the
# enclosed entity SHOULD be considered as a modified version of the one
# residing on the origin server.

1.) Discard the "application/gif" representation and consider, from now
    on, the "application/png" entity PUT as the sole, modified
    representation of <http://example.org/image>.
2.) Convert the "application/png" entity into a "application/gif"
    variant; both serve as modified representations of
    <http://example.org/image>.

Granted, if the two representations are available as source resources,
too, as advertised by Content-Location, modifying the source resources
directly is probably the better way. (Also, for resources which vary by
Content-Language option 2 is probably not an viable option.)

But there may be cases where the sources are not available at their own
URIs. When negotiating "text/plain" solely on Accept-Charset, e.g,
conversion could easily occur on the fly; there is no reason to provide
source resources for all the $n$ charsets out there.

So, what makes PUT inherently unsuitable for negotiated resources? I
don't see a compelling reason for it.

Regards,

Andreas

Received on Thursday, 5 July 2007 15:04:40 UTC