I could go either way on this. MAY or MUST, so long as the spec is clear on what is expected.
- James Thomas Broyer wrote: > 2006/4/26, Thomas Broyer <[EMAIL PROTECTED]>: >> "The server MAY return the Atom Entry representing the newly-created >> resource in the response body. If it does so, it MUST then include a >> Content-Location header with the same value as the Location header. >> Clients MUST NOT assume that such an Atom Entry is a full >> representation of the member resource and SHOULD perform a GET on the >> member resource before editing. Any Atom Entry Document returned in >> the response body without an accompanying Content-Location header, or >> with a Content-Location header whose value is different from the >> Location header MUST NOT be treated as a representation of the newly >> created resource." >> >> The second has the advantage of allowing servers to return some >> information as an Atom Entry without it representing the newly-created >> resource > > Note that this is what Roy T. Fielding suggested doing a month ago > [1]. At that time, James Holderness objected [2] that for "Media > Collections", the Location header would contain the URI of the "media > resource", not its Atom Entry representation. Since PaceMediaEntries > changes this behavior, this solution can now be used with no > limitation. > > Just for the record… > > Please also note that the returned entity when Content-Location == > Location has not to be an Atom Entry Document (conneg could take place > at the "Location" URI), but I think it's clearer. Also, given that the > "Location" URI MUST/SHOULD be able to return an Atom Entry Document > representation, I can't see any reason we couldn't enforce the server > returning the Atom Entry representation preferably to any other that > could be obtained with conneg. > > [1] http://www.imc.org/atom-protocol/mail-archive/msg04758.html > [2] http://www.imc.org/atom-protocol/mail-archive/msg04759.html > > -- > Thomas Broyer > >
