On 4/24/06, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Alrighty folks, it's been several weeks. Several implementations are
> out there being tested. We've talked about it, hashed it over, etc.
> Media collections are broken. Here's a fresh attempt at fixing them.
>
> http://www.intertwingly.net/wiki/pie/PaceMediaEntries
I like the idea of having only one collection type. I also
like the idea of leveraging the "enclosure" link.
+1
Some other comments in line:
> {{{
> 8. Collections
>
> 8.1 Creating resources with POST
>
> To add members to a collection, clients send POST requests to the
> collection's URI. Collections MAY impose constraints on the media-types
> of request entities POSTed to the collection and MAY generate a response
> with a status code of 415 ("Unsupported Media Type"). On successful
> creation, the response to the POST request MUST return a Location:
> header with the URI of an Atom Entry Document representing the newly
> created resource. If the server includes a body in the response, the
> entity MUST be an Atom Entry Document representing the newly-created
> resource, equivalent to that which would appear in the collection's feed
> document.
"equivalent to that which would appear in the collection's feed
document." I would
rephrase to indicate that it MAY be an incomplete entry, like entries
that appear in feed documents. I don't think putting in a constraint that
they be 'exactly' the same helps interop.
After looking at Google's GData I believe that a server MUST return
an Atom Entry in the response to a successful POST. This
rises to a MUST because the entry contains the atom:id,
which is the only way to 'find' that entry when it appears in
the feed document.
In the GData implementation the value of the Location: header isn't
the same as link/@rel="edit" value. Each 'version' of an entry gets
its own URI
and it is that specific URI that PUT and DELETE requests must be
sent to. You could argue that this could have been solved by using
ETags: and If-Modified:, which is true, but I'm not convinced that
is true for every eventuality and that there may be other compelling reasons
to have varying edit URIs from what appears in the Location: header.
So to track a newly created resource the only invariant is the server assigned
atom:id and the only way to get that is to have the server return
an Atom Entry upon a successful POST. (OK, we could put the atom:id
in a header in the POST response, but that seems a little awkward.)
--
Joe Gregorio http://bitworking.org
