Méthode RESTful pour créer plusieurs éléments en une seule requête

Question

Je travaille sur un petit programme client-serveur pour collecter les commandes. Je veux faire cela d'une manière "REST(ful)".

Ce que je veux faire, c'est :

Collecte de toutes les lignes de commande (produit et quantité) et envoi de la commande complète au serveur.

Pour l'instant, je vois deux options pour y parvenir :

1. Envoyer chaque ligne de commande au serveur : POST qty et product_id

En fait, je ne veux pas faire cela parce que je veux limiter le nombre de demandes au serveur, donc l'option 2 :

2. Rassemblez toutes les lignes de commande et envoyez-les au serveur en une seule fois.

Comment dois-je mettre en œuvre l'option 2 ? J'ai quelques idées : Envelopper toutes les lignes de commande dans un objet JSON et l'envoyer au serveur ou utiliser un tableau pour afficher les lignes de commande.

Est-ce une bonne idée ou une bonne pratique de mettre en œuvre l'option 2, et si oui, comment dois-je m'y prendre ?

Qu'est-ce qu'une bonne pratique ?

Answer 1

Je pense qu'une autre façon correcte d'aborder cette question serait de créer une autre ressource qui représente votre collection de ressources. Par exemple, imaginons que nous ayons un point de terminaison tel que /api/sheep/{id} et nous pouvons POST à /api/sheep pour créer une ressource ovine.

Maintenant, si nous voulons soutenir la création en masse, nous devrions envisager une nouvelle ressource de flocage à /api/flock (o /api/<your-resource>-collection si vous ne trouvez pas de nom plus significatif). N'oubliez pas que Les ressources ne doivent pas nécessairement correspondre à votre base de données ou à vos modèles d'application. . Il s'agit d'une idée fausse très répandue.

Les ressources sont une représentation de niveau supérieur, sans lien avec vos données. L'exploitation d'une ressource peut avoir des effets secondaires importants, comme le déclenchement d'une alerte pour un utilisateur, la mise à jour d'autres données connexes, le lancement d'un processus de longue durée, etc. Par exemple, nous pourrions mapper un système de fichiers ou même le système unix ps en tant qu'API REST.

Je pense que l'on peut supposer que l'exploitation d'une ressource peut également signifier la création de plusieurs autres entités comme effet secondaire.

Answer 2

Bien que les opérations de masse (par exemple, la création de lots) soient essentielles dans de nombreux systèmes, elles ne sont pas formellement prises en compte par le style d'architecture RESTful.

J'ai découvert que le POSTing d'une collection comme vous l'avez suggéré fonctionne en principe, mais des problèmes surviennent lorsque vous devez signaler des échecs en réponse à une telle requête. Ces problèmes sont plus graves lorsque plusieurs échecs se produisent pour des causes différentes ou lorsque le serveur ne prend pas en charge les transactions. Je vous suggère que s'il n'y a pas de problème de performance, par exemple lorsque le fournisseur de services est sur le LAN (pas le WAN) ou que les données sont relativement petites, cela vaut la peine d'envoyer 100 requêtes POST au serveur. Restez simple, commencez par des demandes distinctes et si vous avez un problème de performances, essayez d'optimiser.

Answer 3

Facebook explique comment procéder : https://developers.facebook.com/docs/graph-api/making-multiple-requests

Demandes simples par lots

L'API batch reçoit un tableau de requêtes HTTP logiques représentées par sous forme de tableaux JSON - chaque demande possède une méthode (correspondant à la méthode HTTP GET/PUT/POST/DELETE, etc.), un relative_url (la partie de l'URL après le après graph.facebook.com), un tableau d'en-têtes facultatif (correspondant aux en-têtes aux en-têtes HTTP) et un corps facultatif (pour les demandes POST et PUT). L'adresse Batch API renvoie un tableau de réponses HTTP logiques représentées sous forme de tableaux tableaux JSON - chaque réponse comporte un code d'état, un tableau d'en-têtes facultatif et un corps facultatif (qui est une chaîne codée JSON).

Answer 4

Votre idée me semble valable. L'implémentation est une question de préférence. Vous pouvez utiliser JSON ou simplement des paramètres pour cela (tableau "order_lines[]") et faire

POST /orders

Puisque vous allez créer plusieurs ressources à la fois dans une seule action (commande et ses lignes), il est essentiel de valider chacune d'entre elles et de ne les enregistrer que si elles passent toutes la validation, c'est-à-dire que vous devez le faire dans une transaction.

Answer 5

Je me suis penché sur la question récemment, et voici ce que je cherche à faire.

Si un POST qui ajoute plusieurs ressources réussit, renvoyez un 200 OK (j'envisageais un 201, mais l'utilisateur n'arrive finalement pas sur une ressource qui a été créée) ainsi qu'une page qui affiche toutes les ressources qui ont été ajoutées, en lecture seule ou modifiable. Par exemple, un utilisateur peut sélectionner et envoyer plusieurs images dans une galerie à l'aide d'un formulaire ne comportant qu'une seule entrée de fichier. Si la requête POST réussit dans son intégralité, l'utilisateur se voit présenter un ensemble de formulaires pour chaque représentation de ressource d'image créée qui lui permet de spécifier plus de détails sur chacune (nom, description, etc.).

Si la création d'une ou plusieurs ressources échoue, le gestionnaire POST interrompt tout traitement et ajoute chaque message d'erreur individuel à un tableau. Ensuite, un conflit 419 est renvoyé et l'utilisateur est dirigé vers une page d'erreur de conflit 419 qui présente le contenu du tableau d'erreurs, ainsi qu'un moyen de revenir au formulaire qui a été soumis.