2006/6/3, Joe Gregorio <[EMAIL PROTECTED]>:
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).
Well, that's how HTTP is designed/defined: if a POST results in the
creation of a new resource identified by an URI, that resource's URI
is returned in the Location header of the 201 (Created) response; you
can send a representation of the created resource as the response body
and then can use the Content-Location header to explicitly tell the
client that the response body is a representation of the newly-created
resource, as identified by the same URI (Location ==
Content-Location).
Similarly, when you do a PUT to update a resource, the server might
modify it and might not send you a representation of the resource in
the response body, so you'll have to do a GET just after the PUT to
synchronize your local copy with the remote one.
Well, OK, you were talking about retrieving the atom:id, not about
synchronizing local vs. remote representations… I personnaly still
think servers shouldn't change the POSTed atom:id, so the two
scenarios (POST and PUT) are almost the same…
--
Thomas Broyer
