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
