[99s-extend] I need your feedback about this cowboy_rest handler.

[Stéphane Wirtel]

On 27 Aug 2014, at 12:03, Loïc Hoguin wrote:

> Hey,
>
> On 08/27/2014 12:29 PM, Stéphane Wirtel wrote:
>> Hi all,
>>
>> This night, I wrote an example because I wanted to show you my work.
>>
>> I have one handler for the concept of collections (in this case, 
>> tasks).
>>
>> In this handler, I want these following methods:
>>
>> POST /:collection
>> GET /:collection
>> DELETE /:collection
>> PUT /:collection
>> HEAD /:collection
>>
>> :collection is a string, example: /tasks1
>>
>> HEAD /:collection (/tasks1)
>> StatusCode:
>>  * 200 ok
>>  * 404 not found
>>
>> GET /:collection (/tasks1)
>> Gets information about the collection
>> StatusCode:
>>  * 200 ok
>>  * 404 not found
>>
>> PUT /:collection (/tasks1)
>> Create a new collection of tasks
>> Status_Code:
>>  * 201 created
>>  Response: an object, in msgpack or json and I need to had a
>> location header
>>  * 412 precondition failed, the collection name already exists
>>  Response: an object, in msgpack or json with the error (already
>> exists)
>>
>> POST /:collection (/tasks1)
>> Add a new item in the collection, a new task
>> StatusCode:
>>  * 201 created
>>  * 202 accepted
>>  * 404 not found (error in the collection name)
>> Response: need to add a location header and return an object in 
>> msgpack
>> or json.
>>
>> DELETE /:collection (/tasks1)
>> Delete all the tasks
>> Status_Code:
>>  * 200 ok.
>>  * 404 not found
>> In the case of 200, we need to return an object in msgpack or json.
>>
>>
>> I provided a code and If you can help me, because I think cowboy_rest 
>> is
>> a good solution, but I also think I will have some problems with my
>> service.
>>
>> Examples:
>> * delete_completed, I need to write the serialisation in the
>> delete_completed function and not with the help of the defined 
>> callbacks
>> of content_types_provided.
>
> What's the problem? The callbacks you set in content_types_provided 
> are there to provide the *resource*. If you set a body in response to 
> the DELETE method you are not sending the resource but information 
> about the result of the operation.
Ok, in this case, I understand. thanks
>
>> * for PUT, I need to return a location header, should I add it in the
>> is_conflict
>> function?
>
> I would say in the callback you set in content_types_accepted. But...
Works fine in the is_conflict function.
>
>> * for PUT, how I have a 201? I have read the rest_flowchart and I 
>> need
>> to specify the location header ok, but where? in the is_conflict 
>> function?
>
> Why do you need a 201? If you PUT a collection to /:collection then 
> this is already the location of the collection. I am not sure what you 
> are trying to do there exactly?
In this case, the PUT method is used for the creation of the resource 
and not for the update. This is the reason of the 201 status code.

In the rest_flowchart graph for the PUT/POST methods, what is the node 
"new resource" ? Is it just the {true, Req, State} from the callback 
defined in the content_types_accepted?

PS: I retested and now, I have my 201 with PUT, just resource_exists has 
to return false and not true ;-)

Thanks

--
Stéphane Wirtel - http://wirtel.be - @matrixise