Heya!

As you may have noticed, I and Michael Gallego (Bakura) have been working
on ZfrRest lately. It is a doctrine-related library, so not for everyone
out there, but here's some answers for you (you may as well check out the
library!).

POST /users/[userId]/customers - adds a customer to that particular
collection for the user
DELETE /users/[userId]/customers/[customerId] - removes a particular
customer from the collection of customers of that particular users (may
remove it completely if necessary, but that's up to your business logic)

ZfrRest basically builds the first step for you: retrieving the resource
(collection, item or association) and passes it to a designated controller
(which can be configured by collection, association or item). Then it's up
to the controller to decide what to do. If you come up with a mental model
that fits your needs, you can just use the same two controllers (one for a
collection, one for a single item - yes, those are different resource types
and have to be handled separately!) for every mapped resource.

Just my 2 cents

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On 31 May 2013 22:47, esheffield [via Zend Framework Community] <
[email protected]> wrote:

> Hi all,
>
> I'm wondering if anyone out there in the community has any experience with
> RESTful APIs where entities have associations.
>
> In my application, for example, I have two Doctrine entities, user and
> customer, which have a many-to-many relationship. With REST, I can call:
>
> GET /users/[userId]
>
> to get information associated with a user like first name, email, etc.
> However, because of the many-to-many relationship, a user also has a
> collection of Customers as one its properties. To get information about
> this relationship I would call
>
> GET /users/[userId]/customers  or
> GET /users/[userid]/customers/[customerId]
>
> This works well enough, but what should happen if you were to do a POST,
> PUT, or DELETE to one of those routes? How should it behave? For example,
> should DELETE /users/[userid]/customers/[customerId] actually remove that
> customer from the database, or just remove it from that user's collection
> of customers? One thought I've had is to keep such routes as GET only,
> essentially as convenience for getting information about associations. But
> then how would you add/remove associations? You could make PUTs to
> /users/[userId] and /customer/[customerId], but this would require some
> added complexity in the REST controllers to find the proper resource and
> add it to or remove it from the collection.
>
> If anyone has any best practices or thoughts on how to design this kind of
> REST api, it would be greatly appreciated. I'd also be curious how people
> have approached this problem from a ZF2 perspective in terms of setting up
> the routes and controllers.
>
> Thanks!
> ------------
> Evan Sheffield
> iVantage Health Analytics
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://zend-framework-community.634137.n4.nabble.com/ZF2-RESTful-API-for-nested-resources-tp4660188.html
>  To start a new topic under Zend Framework, email
> [email protected]
> To unsubscribe from Zend Framework Community, click 
> here<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=634137&code=b2NyYW1pdXNAZ21haWwuY29tfDYzNDEzN3wxNzE0OTI1MTk4>
> .
> NAML<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/ZF2-RESTful-API-for-nested-resources-tp4660188p4660190.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Reply via email to