Méthode RESTful pour créer plusieurs éléments en une seule demande

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

Ce que je veux faire, c'est:

Collecter toutes les lignes de commande (produit et quantité) et envoyer la commande complète au serveur

Pour le moment, je vois deux options pour le faire:

1. Envoyez 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 requêtes au serveur, donc option 2:

2. Collectez toutes les lignes de commande et envoyez-les au serveur à la fois.

Comment dois-je mettre en œuvre l'option 2? Voici quelques idées que j'ai: enveloppez toutes les lignes de commande dans un objet JSON et envoyez-le au serveur ou utilisez un tableau pour publier 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 le faire?

Qu'est-ce qu'une bonne pratique?

Je crois qu'une autre manière correcte d'aborder cela serait de créer une autre ressource qui représente votre collection de ressources. Exemple, imaginez que nous avons un point de terminaison comme /api/sheep/{id}et que nous pouvons POSTER /api/sheeppour créer une ressource mouton.

Maintenant, si nous voulons prendre en charge la création en bloc, nous devrions envisager une nouvelle ressource de flock à /api/flock(ou /api/<your-resource>-collections'il vous manque un nom plus significatif). N'oubliez pas que les ressources n'ont pas besoin d'être mappées à votre base de données ou aux modèles d'application . C'est une idée fausse courante.

Les ressources sont une représentation de plus haut niveau, sans rapport avec vos données. Opérer sur une ressource peut avoir des effets secondaires importants, comme déclencher une alerte à un utilisateur, mettre à jour d'autres données associées, lancer un processus de longue durée, etc. Par exemple, nous pourrions mapper un système de fichiers ou même la pscommande unix en API REST.

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

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

J'ai trouvé que publier une collection comme vous l'avez suggéré fonctionne essentiellement, mais des problèmes surviennent lorsque vous devez signaler des échecs en réponse à une telle demande. Ces problèmes sont pires lorsque plusieurs échecs se produisent pour différentes causes 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 performances, par exemple lorsque le fournisseur de services est sur le LAN (pas sur 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 performance, essayez d'optimiser.

Facebook explique comment faire cela: https://developers.facebook.com/docs/graph-api/making-multiple-requests

Demandes groupées simples

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

Votre idée me semble valable. La mise en œuvre est une question de votre 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 plus de ressources à la fois en une seule action (commande et ses lignes), il est vital de valider chacune d'entre elles et de les sauvegarder uniquement si elles réussissent toutes la validation, c'est-à-dire. vous devriez le faire dans une transaction.

Je suppose qu'il est préférable d'envoyer des demandes séparées dans une seule connexion . Bien sûr, votre serveur Web doit le prendre en charge

En fait, je me suis battu avec ça ces derniers temps, et voici ce vers quoi je travaille.

Si un POST qui ajoute plusieurs ressources réussit, renvoyez un 200 OK (j'envisageais un 201, mais l'utilisateur n'atterrit finalement pas sur une ressource qui a été créée) avec une page qui affiche toutes les ressources qui ont été ajoutées, soit en lecture -seulement ou mode modifiable. Par exemple, un utilisateur peut sélectionner et POST plusieurs images dans une galerie en utilisant un formulaire ne comprenant 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 image créée qui lui permet de spécifier plus de détails sur chacun (nom, description, etc.).

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

Vous ne voudrez pas envoyer les en-têtes HTTP pour 100 lignes de commande. Vous ne souhaitez pas non plus générer plus de demandes que nécessaire.

Envoyez toute la commande dans un objet JSON au serveur, à: serveur / commande ou serveur / commande / nouveau. Renvoie quelque chose qui pointe vers: server / order / order_id

Pensez également à utiliser CREATE PUT au lieu de POST