On 6/2/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
You have the value of the Location response header, which you can dereference to retrieve the Atom Entry Document representation of th newly-create resource. Sending that Atom Entry (or a modified form) as the response body (along with an appropriate Content-Location header) is just an optimization trick so that clients won't need to perform a GET just after the response to the POST, nothing more, nothing less.
I always considered this chain of custody to be a little awkward. If I POST a new entry, in order to keep track of it I need to post the entry, get the Location: header in the response and then do a GET on that URI to get the updated entry with the atom:id. Entry(POST) -> Location: <URI> -> Entry(GET) -> atom:id I saw returning the Entry as a method to provide the atom:id in the response, making is simple POST an entry and the the atom:id in the response. Entry(POST) -> atom:id Both approaches work and if other people don't see the first case as awkward I'd be OK with an Atom Entry response body being a MAY (with a note explaining the Location: == Content-Location: optimization). -joe -- Joe Gregorio http://bitworking.org
