2006/5/27, James M Snell <[EMAIL PROTECTED]>:
Thomas Broyer wrote: >[snip] > First, there's no reason for the MUST in "MUST be an Atom Entry > Document representing the newly-created resource"; I'm still > uncomfortable with the second paragraph, and I see no reason for the > SHOULD in "SHOULD also return a response body". > This has been debated several times already. I don't see what the MAY buys us in terms of interop as it leads to the possibility that, with some server implementations, I could post an entry and have absolutely no idea how to go back and edit it, or even find it later.
My guess is that you have the "Location" header, but reading again the Pace, it seems that the given URI –when dereferenced– is not enforced to returning an Atom Entry Document in response to an HTTP GET. That should be the "MUST", there's no reason for anything but a "MAY" on the response body.
Limiting the SHOULD and MUST to 201 responses is a compromise.
We don't need such constraints, they're just optimizations: if the response to the POST contains no response body or one which is not an Atom Entry Document representation of the newly-created resource (Location != Content-Location), you can still dereference the URI given in the Location header to get an Atom Entry Document representation of the newly created resource. This URI SHOULD NOT return a 404 (Not Found), as a 201 (Created) response tells you that the resource has already been created (a server "MUST create the resource before returning the 201 status code", from HTTP/1.1, section 10.2.2). If you want something for the case where the resource has not yet been created, then consider adding a constraint so that 202 (Accepted) responses SHOULD contain a Location header giving the URI where the resource will be available (if it ever becomes available). -- Thomas Broyer
