Routes RESTful pour has_many: à travers les relations?

Question

J'ai 2 modèles - Utilisateur et Activité - qui sont liés par un has_many: en utilisant le modèle UserActivity. Un utilisateur peut "vouloir" ou "faire" une activité, ce qui crée un enregistrement UserActivity et définit le booléen approprié.

Que recommanderiez-vous pour gérer ces actions lors de la création de routes et d'actions de contrôleur? Est-ce que quelque chose comme activity /: id/want, et activity /: id/done est le plus logique et a donc 2 routes membres sous la ressource d'activité? Ou aurait-il plus de sens de simplement utiliser les actions de mise à jour/créer dans le contrôleur user_activity, avec la publication dans/user_activity pour créer, et mettre à/user_activity /: id pour mettre à jour?

Answer 1

J'irais avec la dernière approche, c'est-à-dire en autorisant l'accès POST/PUT à "user_activity". Dans le monde REST, ceci est considéré comme une nouvelle ressource même si elle forme simplement une relation entre les ressources "utilisateur" et "activité". Une idée qui vient à l'esprit est de séparer également les types d'activité "désirés" ou "terminés" en tant que nouvelle ressource (par exemple "état"). L'idée est propre car elle est même sans elle, mais s'il y a une chance que vous deviez étendre la liste à quelque chose en plus de "vouloir" ou "fini" (par exemple "un jour/peut-être"), cela peut être plus facile pour le définir comme une nouvelle ressource plutôt maintenant que plus tard.

Alors vous auriez:

• ressources utilisateur: /user et /user/id
• activité ressource: /activity et /activity/id
• ressource d'état: /status et /status/id
• ressources qui forme la relation entre l'utilisateur, activité et ressource: /user-activity et /user-activity/id

En fonction de votre conception URI vous pouvez travailler dans URIs accessable qui vous permettra d'obtenir toutes les activités d'un utilisateur qui se trouvent dans un état spécifique, par exemple: /user-activity/user/{userId}/status/{statusId}

---

S'il vous plaît noter: Je ne peux pas donner de conseil sur les spécificités de Ruby-on-Rails (comme je viens du monde PHP), mais je pense que les principes (REST) ​​devraient être très similaires.