[99s-extend] PUT on new resource and status 201

[Camille Troillard]

Hi Stefan,


On 14 Oct 2014, at 10:05, Stefan Strigler <stefan.strigler at gmail.com> wrote:

> just subscribed yesterday and now that's already my first question.
> 
> I'm referring to http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you have a PUT on a new resource the diagram suggests that the response's status code depends on whether you've set a location and/or body.

This is correct, I have experience this behaviour on Cowboy 1.0.0 and 2.0.0-pre.1.


> But when looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would always return a 201. No matter what. I think the code is right, but the diagram needs to be fixed. 

Could you be more specific?
I’m afraid it is not how it works for me.


> But then I'm not totally sure how to interpret http://tools.ietf.org/html/rfc2616#section-10.2.2 which states
> 
>    The newly created resource can be referenced by the URI(s)
>    returned in the entity of the response, with the most specific URI
>    for the resource given by a Location header field.
> 
> Because currently it is totally possible to not have a location header set (just as no body) for the response. In my opinion the current code behaves good enough and it's up to the service to ensure the requirements as stated by the RFC. Should cowboy enforce a header field? Should it try to figure that out on its own?

I think how Cowboy does is best at the moment.
I like to have the freedom to specify myself the Location, especially when PUT-ting new resources.


A bit off topic, I think this article is interesting regarding RFC-2616.

	https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

Given that, you might want to have a look at RFC-7231, section 3.1.4.2:

	http://tools.ietf.org/html/rfc7231#section-3.1.4.2.


Camille

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20141014/77f74bf0/attachment-0001.html>