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. > it looks to me that as server already MUST return Location then this is not required: an APP client MUST do GET to retrieve atom:entry (and will get atom:id that was possibly changed by server) *before* editing entry (it needs to do it anyway to find atom:[EMAIL PROTECTED]"edit")
did i miss something? thanks, alek > 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 > > > -- --- Memorable Quote from Firefly (105. Out Of Gas) -Ship like this, be with you until you die -That's because it's a deathtrap
