In our impl, the edit-resource URI is the same as the edit URI. If we
PUT an application/atom+xml to an edit uri for a "file"-type entry, the
assumption is that it's an atom entry (Posted atom feeds are rejected as
a bad request). If we PUT anything other than application/atom+xml, the
assumption is that it's a media resource. DELETE and PUT are only ever
performed on a single URI and it works great. We use a different URI
for GET'ing the media resource.
<entry>
...
<link rel="edit" type="application/atom+xml"
href="/oa/service/atom/activitynode?uuid={uuid}" />
<link rel="edit-resource" type="image/png"
href="/oa/service/atom/activitynode?uuid={uuid}" />
<content type="image/png"
href="/oa/service/download/{uuid}/myfile.png" />
...
</entry>
Works just fine for us, although I would not want to see it mandated in
the spec. There are valid reasons why one may want to separate the edit
and edit-resource URI's (e.g. the media resource is stored on a
different host than the entry).
- James
Thomas Broyer wrote:
>
> 2006/5/7, Bill de hÓra <[EMAIL PROTECTED]>:
>> It doesn't rationalize rel="edit-resource". And it needs to; editing
>> non-header metadata about a resource v editing the resource is a first
>> class webarch headache. How many resources are in play with a media
>> entry?
>
> I was thinking about the Atom Publishing Protocol wrt the WebArch,
> REST, HTTP et al. and this came to my mind:
>
> Why couldn't there be a single MemberIRI whatever is updatable?
> (MemberIRI is given by atom:[EMAIL PROTECTED]"edit"]/@href)
> * if you PUT an Atom Entry Document and the server doesn't allow you
> to update the metadata associated with the resource, it will send a
> 415 (Unsupported Media Type) –or 422 (Unprocessable Entity) if the
> atom:content itself is of type application/atom+xml (i.e. and is an
> Atom Entry Document with a different atom:id or Atom Feed Document),
> which I think shouldn't be supported by the protocol, but, well,
> that's my opinion…–
> * if you PUT anything else, you're asking to update the "media
> resource" (I really hate that name, as it's not another resource, just
> another representation…), the one which is retrievable at another IRI
> given by the atom:content/@src attribute.
>
> As there would be a single "edit IRI", there's no problem any more
> about what is affected by DELETE (or eventually other methods such as
> COPY, MOVE or BIND).
>
> I really think The Way To Go is having a *single* resource, with
> eventually more than one representation (and at least an Atom Entry
> Document representation), each of which might (must?) have a distinct
> IRI. The "MemberIRI" would then always be the one of the Atom Entry
> Document representation.
>
>
>
> The problem I'm facing is that some fields in the Atom Entry
> representation might not be editable (e.g.
> atom:[EMAIL PROTECTED]"alternate"], or imagine if there were
> atom:[EMAIL PROTECTED]"parent"] referencing the containing collection(s) or
> atom:[EMAIL PROTECTED]"binding"] giving an alternate IRI for the same
> resource –both parly similar to D:parent-set/D:parent of WebDAV
> Binding Extensions [1]–) while others are.
> How is the server supposed to behave if the client PUTs an entry with
> updated values for those read-only fields (or additional values, or
> without those fields)?
> A simple answer would be "ignore the new values" (annoying if those
> changes were intended by the end user) or "reject the request with a
> 422 (Unprocessable Entity)" (can lead to big interop problems if those
> changes are not from the user but its client software). A 207
> (Multi-Status) would work but is not really "simple" (clients needs to
> parse the WebDAV multistatus response format), except if the rejected
> changes can be integrated into the Atom Entry response body (which
> would then be mandatory for 207 responses), but it seems to me that it
> violates REST: rejected changes are not part of the state of the
> resource but relate to the request/response pair only and its intended
> action; however, HTTP doesn't dictate that the entity returned in
> response to a PUT has to be the updates resource representation, so
> that might be OK after all…
>
> How are people on the WG dealing with this?
>
> [1] http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html
>
> --
> Thomas Broyer
>
>
