12

I have read through the documentation many times over and search all over for the answer to this question but have come up short. Specifically I've looked at Defining the service and the Cornice API for a service and at Defining resource for resource.

I'm currently building a REST API that will have a similar structure to this:

GET /clients             # Gets a list of clients
GET /clients/{id}        # Gets a specific client
GET /clients/{id}/users  # Gets a specific clients users

What would be the best way to go about this? Should I use a service or a resource or both? And, if both, how?

Tim Tisdall
  • 9,914
  • 3
  • 52
  • 82
Dan P.
  • 1,433
  • 1
  • 16
  • 28
  • 1
    I also have a question about this. The examples show using a matchdict, ``/resourcename/{id}`` in the path, but what if I need the ability to PUT or POST. Should I just remove the {id} matchdict and simply have the path go to ``/resourcename`` and check for the presence of an ``id`` in the specific put/get method instead since it should not really exist in the POST? – Thomas Farvour Jan 30 '14 at 15:01
  • @ThomasFarvour While you have probably already figured it out after 3.5 years, I want to answer this for other readers. You define it as @service.put() when the `id` is known/resource is updated. For a POST you will want to add data in the form-data or json-payload, but you'll not know the `id`, otherwise it would be a PUT by the REST-definition. – Christian Benke Sep 04 '17 at 16:07

2 Answers2

7

Resources are high-level convenience, services offer lower level control.

I am just learning cornice myself. Looking at the source code, a Resource creates Services internally, one for the item and one for the collection (if a collection path is specified). The resource also adds views to the services for each method defined with an http verb as the name or in the form collection_[verb].

So there is little difference except that resources are a neat, structured way to define services.

Community
  • 1
  • 1
Graeme Stuart
  • 5,837
  • 2
  • 26
  • 46
  • That's what I've come to realize after using them for a bit. That pretty interesting that the Resource creates a Service, nice find. – Dan P. Mar 29 '14 at 21:30
6

The resource decorator uses a url for the collection, as well as a url pattern for an object.

collection_path=/rest/users path=/rest/users/{id}

The resource decorator is best used in view classes where you can use get/put/post/delete methods on the objects, as well as collection_get, collection_put, etc. on the collection. I have some examples here:

https://github.com/umeboshi2/trumpet/blob/master/trumpet/views/rest/users.py

Since I make heavy use of the resource decorator and view classes, I haven't found a need for the service function, but it allows you to create get,put,post decorators that wrap view callable functions.

If you are using backbone.js on the client side, the resource decorator and url examples work well with the Backbone collections and models.

umeboshi
  • 767
  • 1
  • 6
  • 12