Comment mieux structurer un point de terminaison API RESTful

Question

Je travaille sur une transition de mon application d'une implémentation PHP étroitement couplée à une implémentation RESTful. (application actuelle au http://coinvault.tanichols.com)

L'application conserve une collection de pièces de monnaie (les quartiers de l'État, les dollars présidentiels, etc) et les utilisateurs. Un utilisateur peut également «collecter» une pièce de monnaie, représentée comme une relation multiple entre l'utilisateur et les tables de pièces.

J'ai créé le tableau suivant des combinaisons verbe et point final:

GET /coins    - Get all coins 
POST /coins    - Create a new coin 
GET /coins/CID   - Get a coin 
PUT /coins/CID   - Update a coin 
DELETE /coins/CID   - Delete a coin 

GET /users    - Get all users 
POST /users    - Create a new user 
GET /users/UID   - Get a user 
PUT /users/UID   - Update a user 
DELETE /users/UID   - Delete a user 

Ce que je vais avoir des problèmes avec est la bonne façon/accepté d'exposer l'information de nombreux-many table. Par exemple, je pourrais utiliser l'ensemble suivant des itinéraires:

GET /users/UID/coins  - Get coins for a user 
POST /users/UID/coins  - Create a coin for a user 
GET /users/UID/coins/CID - Get a specific coin for a user 
PUT /users/UID/coins/CID - Update a specific coin for a user 
DELETE /users/UID/coins/CID - Delete a specific coin for a user 

ou je pourrais inverser cela:

GET /coins/CID/users/UID - Get a specific coin for a user 
PUT /coins/CID/users/UID - Update a specific coin for a user 
DELETE /coins/CID/users/UID - Delete a specific coin for a user 

Q1: Est-ce un de ces préféré sur l'autre? Existe-t-il une façon standard ou acceptée de planifier ces types de routes?

Je pourrais aussi exposer cette fonctionnalité avec la route et le filtre suivant:

GET /coins?user_id=1  - Get all coins belonging to a user 

Q2: Est-ce une meilleure approche, ou pire? Cela ajoute-t-il un 'poids' inutile à la route/coins? Finalement, il y a la situation où je veux donner accès à certaines agrégations, comme le compte du nombre de fois qu'une pièce particulière a été collectée, à des fins de reporting et d'analyse. Pour celui-ci, je suis complètement à la perte d'où commencer, ou comment aborder le problème.

Q3: Comment exposer de telles agrégations via une API RESTful? Qu'est-ce qu'un itinéraire significatif pour cela?

Answer 1

Q1:

La façon dont vous représentez des collections et des objets est valable dans l'absolu, mais votre première proposition est valide dans votre contexte:

GET /users/UID/coins  - Get coins for a user 
POST /users/UID/coins  - Create a coin for a user 
GET /users/UID/coins/CID - Get a specific coin for a user 
PUT /users/UID/coins/CID - Update a specific coin for a user 
DELETE /users/UID/coins/CID - Delete a specific coin for a user 

Si une chose appartient à quelqu'un, vous le représenter avec/someones/SID/choses/TID.

Q2:

Cette proposition:

GET /coins?user_id=1  - Get all coins belonging to a user 

est certainement pas une bonne idée, il va à l'encontre REST meilleures pratiques.

Q3:

Ce n'est pas une question d'agrégation, ces données sont liées à une pièce de monnaie, donc vous pouvez simplement les renvoyer dans les données de GET /coins/CID. La multiplication des points de terminaison n'est certainement pas une bonne idée, surtout si ces données seront toujours nécessaires.