James M Snell wrote: > 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 > but if i do GET to Location URI then i get atom:entry that is the same entry as in media collection atom:feed right?
thanks, alek > 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 >>> >>> >>> >>> >> > > > -- --- Memorable Quote from Firefly (105. Out Of Gas) -Ship like this, be with you until you die -That's because it's a deathtrap
