The question is over how to correlate the posted entry with what is listed in the collection feed. The options are either...
a) POST, GET the Location URI to get the atom:id, then GET the feed and locate the matching entry or b) POST, examine the Atom entry in the response to get the atom:id, the GET the feed and locate the matching entry - James Aleksander Slominski wrote: >[snip] > 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 >> >> >> > >
