Modèles de gestion des opérations par lots dans les services Web REST?

Quels modèles de conception éprouvés existent pour les opérations par lots sur les ressources au sein d'un service Web de style REST?

J'essaie de trouver un équilibre entre les idéaux et la réalité en termes de performance et de stabilité. Nous avons actuellement une API où toutes les opérations sont récupérées à partir d'une ressource de liste (par exemple: GET / user) ou sur une seule instance (PUT / user / 1, DELETE / user / 22, etc.).

Dans certains cas, vous souhaitez mettre à jour un seul champ d'un ensemble complet d'objets. Il semble très inutile d'envoyer la représentation complète de chaque objet dans les deux sens pour mettre à jour le champ.

Dans une API de style RPC, vous pourriez avoir une méthode:

/mail.do?method=markAsRead&messageIds=1,2,3,4... etc. 

Quel est l'équivalent REST ici? Ou est-il acceptable de faire des compromis de temps en temps. Cela ruine-t-il la conception d'ajouter quelques opérations spécifiques où cela améliore vraiment les performances, etc.? Le client dans tous les cas est actuellement un navigateur Web (application javascript côté client).

Un modèle RESTful simple pour les lots consiste à utiliser une ressource de collection. Par exemple, pour supprimer plusieurs messages à la fois.

DELETE /mail?&id=0&id=1&id=2

Il est un peu plus compliqué de mettre à jour par lots des ressources partielles ou des attributs de ressources. Autrement dit, mettez à jour chaque attribut marquéAsRead. Fondamentalement, au lieu de traiter l'attribut comme faisant partie de chaque ressource, vous le traitez comme un compartiment dans lequel placer des ressources. Un exemple a déjà été publié. Je l'ai ajusté un peu.

POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]

En gros, vous mettez à jour la liste des e-mails marqués comme lus.

Vous pouvez également l'utiliser pour affecter plusieurs éléments à la même catégorie.

POST /mail?category=junk
POSTDATA: ids=[0,1,2]

Il est évidemment beaucoup plus compliqué de faire des mises à jour partielles par lots de style iTunes (par exemple, artiste + albumTitle mais pas trackTitle). L'analogie du seau commence à s'effondrer.

POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]

À long terme, il est beaucoup plus facile de mettre à jour une seule ressource partielle ou des attributs de ressource. Utilisez simplement une sous-ressource.

POST /mail/0/markAsRead
POSTDATA: true

Vous pouvez également utiliser des ressources paramétrées. Ceci est moins courant dans les modèles REST, mais est autorisé dans les spécifications URI et HTTP. Un point-virgule divise les paramètres liés horizontalement au sein d'une ressource.

Mettez à jour plusieurs attributs, plusieurs ressources:

POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk

Mettez à jour plusieurs ressources, un seul attribut:

POST /mail/0;1;2/markAsRead
POSTDATA: true

Mettez à jour plusieurs attributs, une seule ressource:

POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk

La créativité RESTful abonde.

Pas du tout - je pense que l'équivalent REST est (ou au moins une solution est) presque exactement cela - une interface spécialisée conçue pour s'adapter à une opération requise par le client.

Je me souviens d'un modèle mentionné dans le livre de Crane and Pascarello Ajax in Action (un excellent livre, au fait - hautement recommandé) dans lequel ils illustrent la mise en œuvre d'une sorte d'objet CommandQueue dont le travail consiste à mettre les requêtes en file d'attente en lots et puis publiez-les périodiquement sur le serveur.

L'objet, si je me souviens bien, contenait essentiellement un tableau de "commandes" - par exemple, pour étendre votre exemple, chacun un enregistrement contenant une commande "markAsRead", un "messageId" et peut-être une référence à un callback / handler fonction - et ensuite selon un calendrier, ou sur une action de l'utilisateur, l'objet de commande serait sérialisé et posté sur le serveur, et le client gérerait le post-traitement conséquent.

Je n'ai pas les détails à portée de main, mais il semble qu'une file d'attente de commandes de ce type serait un moyen de gérer votre problème; cela réduirait considérablement le bavardage global et résumerait l'interface côté serveur d'une manière que vous pourriez trouver plus flexible sur la route.

Mise à jour : Aha! J'ai trouvé un extrait de ce livre en ligne, avec des exemples de code (bien que je suggère toujours de récupérer le livre!). Jetez un œil ici , en commençant par la section 5.5.3:

Ceci est facile à coder mais peut entraîner beaucoup de très petits bits de trafic vers le serveur, ce qui est inefficace et potentiellement déroutant. Si nous voulons contrôler notre trafic, nous pouvons capturer ces mises à jour et les mettre en file d'attente localement , puis les envoyer au serveur par lots à notre guise. Une simple file d'attente de mise à jour implémentée en JavaScript est présentée dans la liste 5.13. [...]

La file d'attente gère deux tableaux. queued est un tableau indexé numériquement, auquel de nouvelles mises à jour sont ajoutées. sent est un tableau associatif, contenant les mises à jour qui ont été envoyées au serveur mais qui attendent une réponse.

Voici deux fonctions pertinentes - une responsable de l'ajout de commandes à la file d'attente ( addCommand), et une responsable de la sérialisation puis de leur envoi au serveur ( fireRequest):

CommandQueue.prototype.addCommand = function(command)
{ 
    if (this.isCommand(command))
    {
        this.queue.append(command,true);
    }
}

CommandQueue.prototype.fireRequest = function()
{
    if (this.queued.length == 0)
    { 
        return; 
    }

    var data="data=";

    for (var i = 0; i < this.queued.length; i++)
    { 
        var cmd = this.queued[i]; 
        if (this.isCommand(cmd))
        {
            data += cmd.toRequestString(); 
            this.sent[cmd.id] = cmd;

            // ... and then send the contents of data in a POST request
        }
    }
}

Cela devrait vous faire avancer. Bonne chance!

Bien que je pense que @Alex est sur la bonne voie, conceptuellement, je pense que cela devrait être l'inverse de ce qui est suggéré.

L'URL est en effet "les ressources que nous ciblons" d'où:

    [GET] mail/1

signifie obtenir l'enregistrement du courrier avec l'ID 1 et

    [PATCH] mail/1 data: mail[markAsRead]=true

signifie patcher l'enregistrement de courrier avec l'ID 1. La chaîne de requête est un "filtre", filtrant les données renvoyées par l'URL.

    [GET] mail?markAsRead=true

Nous demandons donc ici tous les e-mails déjà marqués comme lus. Donc, pour [PATCH] sur ce chemin, il faudrait dire "patcher les enregistrements déjà marqués comme vrais" ... ce qui n'est pas ce que nous essayons de réaliser.

Donc, une méthode par lots, suivant cette réflexion devrait être:

    [PATCH] mail/?id=1,2,3 <the records we are targeting> data: mail[markAsRead]=true

bien sûr, je ne dis pas que c'est vrai REST (qui ne permet pas la manipulation d'enregistrements par lots), mais il suit plutôt la logique déjà existante et utilisée par REST.

Votre langage, "Cela me semble très inutile ...", indique pour moi une tentative d'optimisation prématurée. À moins qu'il ne puisse être démontré que l'envoi de la représentation entière des objets est un impact majeur sur les performances (nous parlons d'inacceptable pour les utilisateurs comme> 150 ms), il est inutile d'essayer de créer un nouveau comportement d'API non standard. N'oubliez pas que plus l'API est simple, plus elle est facile à utiliser.

Pour les suppressions, envoyez ce qui suit car le serveur n'a pas besoin de savoir quoi que ce soit sur l'état de l'objet avant la suppression.

DELETE /emails
POSTDATA: [{id:1},{id:2}]

L'idée suivante est que si une application rencontre des problèmes de performances concernant la mise à jour en masse des objets, il faut envisager de diviser chaque objet en plusieurs objets. De cette façon, la charge utile JSON est une fraction de la taille.

À titre d'exemple, lors de l'envoi d'une réponse pour mettre à jour les statuts «lu» et «archivé» de deux e-mails distincts, vous devrez envoyer ce qui suit:

PUT /emails
POSTDATA: [
            {
              id:1,
              to:"someone@bratwurst.com",
              from:"someguy@frommyville.com",
              subject:"Try this recipe!",
              text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1t Mustard Powder",
              read:true,
              archived:true,
              importance:2,
              labels:["Someone","Mustard"]
            },
            {
              id:2,
              to:"someone@bratwurst.com",
              from:"someguy@frommyville.com",
              subject:"Try this recipe (With Fix)",
              text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1T Mustard Powder, 1t Garlic Powder",
              read:true,
              archived:false,
              importance:1,
              labels:["Someone","Mustard"]
            }
            ]

Je diviserais les composants modifiables de l'e-mail (lu, archivé, importance, étiquettes) en un objet séparé car les autres (vers, depuis, sujet, texte) ne seraient jamais mis à jour.

PUT /email-statuses
POSTDATA: [
            {id:15,read:true,archived:true,importance:2,labels:["Someone","Mustard"]},
            {id:27,read:true,archived:false,importance:1,labels:["Someone","Mustard"]}
          ]

Une autre approche à adopter consiste à tirer parti de l'utilisation d'un PATCH. Pour indiquer explicitement les propriétés que vous envisagez de mettre à jour et que toutes les autres doivent être ignorées.

PATCH /emails
POSTDATA: [
            {
              id:1,
              read:true,
              archived:true
            },
            {
              id:2,
              read:true,
              archived:false
            }
          ]

Les gens déclarent que PATCH doit être implémenté en fournissant un tableau de modifications contenant: action (CRUD), chemin (URL) et changement de valeur. Cela peut être considéré comme une implémentation standard, mais si vous regardez l'intégralité d'une API REST, il s'agit d'une mise en œuvre ponctuelle non intuitive. En outre, la mise en œuvre ci-dessus est de savoir comment GitHub a implémenté PATCH .

Pour résumer, il est possible d'adhérer aux principes RESTful avec des actions par lots tout en conservant des performances acceptables.

L'API google drive dispose d'un système vraiment intéressant pour résoudre ce problème ( voir ici ).

En gros, ils regroupent différentes demandes en une seule Content-Type: multipart/mixeddemande, chaque demande complète individuelle étant séparée par un délimiteur défini. Les en-têtes et le paramètre de requête de la demande par lots sont hérités des demandes individuelles (c'est-à-dire Authorization: Bearer some_token) à moins qu'ils ne soient remplacés dans la demande individuelle.

Exemple : (tiré de leurs documents )

Demande:

POST https://www.googleapis.com/batch

Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963

--END_OF_PART
Content-Length: 337
Content-Type: application/http
content-id: 1
content-transfer-encoding: binary


POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id
Authorization: Bearer authorization_token
Content-Length: 70
Content-Type: application/json; charset=UTF-8


{
  "emailAddress":"example@appsrocks.com",
  "role":"writer",
  "type":"user"
}
--END_OF_PART
Content-Length: 353
Content-Type: application/http
content-id: 2
content-transfer-encoding: binary


POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false
Authorization: Bearer authorization_token
Content-Length: 58
Content-Type: application/json; charset=UTF-8


{
  "domain":"appsrocks.com",
   "role":"reader",
   "type":"domain"
}
--END_OF_PART--

Réponse:

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-1


HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35


{
 "id": "12218244892818058021i"
}


--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-2


HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35


{
 "id": "04109509152946699072k"
}


--batch_6VIxXCQbJoQ_AATxy_GgFUk--

Je serais tenté dans une opération comme celle de votre exemple d'écrire un analyseur de plage.

Ce n'est pas très compliqué de créer un analyseur capable de lire "messageIds = 1-3,7-9,11,12-15". Cela augmenterait certainement l'efficacité des opérations générales couvrant tous les messages et est plus évolutif.

Très bonne publication. Je cherche une solution depuis quelques jours. J'ai proposé une solution consistant à passer une chaîne de requête avec un ensemble d'identifiants séparés par des virgules, comme:

DELETE /my/uri/to/delete?id=1,2,3,4,5

... puis en passant cela à une WHERE INclause dans mon SQL. Cela fonctionne très bien, mais demandez-vous ce que les autres pensent de cette approche.

De mon point de vue, je pense que Facebook a la meilleure implémentation.

Une seule requête HTTP est effectuée avec un paramètre de lot et une pour un jeton.

Dans le lot, un json est envoyé. qui contient une collection de "demandes". Chaque requête a une propriété de méthode (get / post / put / delete / etc ...), et une propriété relative_url (uri du point de terminaison), en plus les méthodes post et put permettent une propriété "body" où les champs à mettre à jour sont envoyés .

plus d'informations sur: Facebook batch API