The Pace has been updated. Section 8.1 now reads as:
<snip>
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. The body of the response MUST include an Atom Entry
Document representing the newly-created resource. Clients MUST NOT
assume that an Atom Entry returned is a full representation of the
member resource and SHOULD perform a GET on the member resource before
editing.
</snip>
Joe Gregorio wrote:
> 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
>
