On Thu, 2010-04-08 at 11:46 +0200, Geert Jansen wrote:
On 04/08/2010 10:12 AM, Mark McLoughlin wrote:
>> For the "POST /vms" triggering VM creation, an alternative pattern
>> would be to return the complete representation of the newly created VM
>> in the response entity-body. Obviously this would only really make
>> sense if there's some extra information to convey, over and above what
>> the client already knows ... I dunno, the initial memory usage or
>> something. The point being to save on an immediate dereference of the
>> Location header provided in the response.
>
> Yep, I agree - the only reason I hadn't done it was laziness :-)
>
> It will be useful is to obtain server-generated defaults like the unique
> ID for the created entity
>
> Fixed in git and the wiki now
According to RFC5023, in case you return an entity with a 201 CREATED
response, you also need to set the "Content-Location" header. The
"Location" header needs to be set always, even if you don't return a
body. Confusingly, Location is an absolute URI, while Content-Location
can be absolute or relative.
Hmm, this seems to be specific to atom publishing, no?
Looking at e.g. the HTTP/1.1 spec, I see "The meaning of the
Content-Location header in PUT or POST requests is undefined"
What the the "Link" header you talk about below?
http://tools.ietf.org/html/draft-nottingham-http-link-header-09
Recommended by bburke in his RESTful Java book as a nice way to allow
clients to get at links with only a HEAD request and without having to
parse response bodies
...
>> I think you're right to use 204 for the DELETE response
code, as long
>> as there's no entity-body. Now there might I guess be a case in the
>> future where some sort of status would be returned, maybe an
>> indication as to which alternative VM any migrated processes ended up
>> on. In that case, the status should revert to 200 OK.
>
> Yeah. I don't love the idea of the status code changing sometime in the
> future, but I guess 2xx is "successful"
>
> Would it be completely broken for us to return 200 from DELETE with an
> empty response body?
I think we should return a 204 NO CONTENT. It is the most correct
response code, and we should set the right precedent. There's no clients
to the API yet so let's make sure that when they arise they expect the
correct return code.
I agree 204 is correct. I was just musing about the prospect of us later
adding content to the response, changing the status code to 200 and
potentially breaking clients that explicitly test for 204
Clients should just check for 2xx, though, so nevermind
Cheers,
Mark.