Opérations non-CRUD dans un service RESTful

Question

Quelle est la manière "RESTful" d'ajouter des opérations non-CRUD à un service RESTful ? Disons que j'ai un service qui permet un accès CRUD aux enregistrements comme ceci :

GET /api/car/123           <- Returns information for the Car object with ID 123
POST /api/car              <- Creates a new car (with properties in the request)
PUT /api/car/123           <- Updates car 123 (with properties in the request)
DELETE /api/car/123        <- Deletes car 123    
POST /api/car/123/wheel/   <- Creates a wheel and associates it to car 123

Si je veux changer la couleur de la voiture, je dois simplement POST /api/car/123 et inclure une variable POST pour la nouvelle couleur.

Mais disons que je veux acheter une voiture, et que cette opération est plus compliquée que la simple mise à jour de la propriété "voiture possédée" d'un enregistrement "utilisateur". Est-ce RESTful de faire quelque chose comme POST /api/car/123/purchase où "achat" est essentiellement un nom de méthode ? Ou dois-je utiliser un verbe HTTP personnalisé, tel que PURCHASE au lieu de POST ?

Ou les opérations non-CRUD sont-elles complètement en dehors du champ d'application de REST ?

Answer 1

Pensez à achat en tant qu'entité commerciale ou ressource dans le dictionnaire RESTful. Ceci étant dit, effectuer un achat revient en fait à créer une nouvelle ressource. Donc :

POST /api/purchase

passera une nouvelle commande. Les détails (utilisateur, voiture, etc.) doivent être référencés par id (ou URI) dans le contenu envoyé à cette adresse.

Peu importe que la commande d'une voiture ne soit pas une simple INSERT dans la base de données. En fait, REST ne consiste pas à exposer les tables de votre base de données comme des opérations CRUD. D'un point de vue logique, vous créez une commande (achat), mais le côté serveur est libre d'effectuer autant d'étapes de traitement qu'il le souhaite.

Vous pouvez même abuser encore plus du protocole HTTP. Utilisez Location pour renvoyer un lien vers une commande nouvellement créée, choisir soigneusement les codes de réponse HTTP pour informer les utilisateurs des problèmes (côté serveur ou client), etc.

Answer 2

La méthode RESTful, telle que je la conçois, ne nécessite pas de nouveaux verbes HTTP, il existe un nom quelque part qui signifie ce que vous devez faire.

Acheter une voiture ? N'est-ce pas

POST /api/order

Answer 3

Ce que vous faites vraiment, c'est créer une commande. Donc, ajoutez une autre ressource pour la commande et le poste et mettez-la pendant le processus de commande.

Pensez en termes de ressources plutôt que d'appels de méthodes.

Pour finaliser la commande, vous devriez probablement POST /api/order//complete ou quelque chose de similaire.

Answer 4

Je pense que les API REST sont utiles à bien d'autres égards que la simple fourniture de sémantique. On ne peut donc pas choisir le style RPC simplement à cause de certains appels qui semblent avoir plus de sens dans le style d'opération RPC. Par exemple, l'API de Google Maps pour trouver l'itinéraire entre deux endroits. Cela ressemble à ceci : http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal

Ils auraient pu l'appeler "findDirections" (verbe) et le traiter comme une opération. Au lieu de cela, ils ont fait de "direction" (nom) une ressource et ont traité la recherche de directions comme une requête sur la ressource directions (bien qu'en interne il ne puisse y avoir de ressource réelle appelée direction et qu'elle puisse être implémentée par une logique métier pour trouver des directions sur la base de paramètres).