Brian Smith wrote:
The specification does not say what the entity represents in a "200 OK" response to a PUT request, so I avoid returning "200 OK" for PUT (I always return 201 or 204).Firstly, 201 in response to PUT makes no sense to me - what did you "create"?
You are right that the HTTP RFC says nothing about the 200 OK response for a PUT request. I wonder why? Anyway, not including this in the spec doesn't prohibit anything either.If the client wants to update a resource and retrieve the new version in a single round-trip, it can use HTTP pipelining or the non-standard batching method of its choice to combine a PUT and a GET request.
The Atompub RFC emphatically says so - we don't want Atompub to be a detailed server implementation guide
The Atom Publishing Protocol is different from many contemporary protocols in that the server is given wide latitude in processing requests from clients.
This implies that the server is within its rights to use HTTP correctly and that clients can interpret HTTP responses from Atompub servers just like they treat a normal HTTP response. This means that a 200 OK response to a PUT request should contain an entity. All the normal rules for constructing a response entity should apply here.
It would be so much easier for everyone if we agreed to a best practice that the response on PUT may contain the full representation of the entry if the response contains the Content-Location header containing the entry's edit link as the value. We would not require any new standards to enable this best practice. If it helps everyone, I am willing to draft this up as an I-D
Nikunj