Si les transactions via REST sont irréalisables, comment REST peut-il être réellement utile ?

Question

Certains disent que cela va implicitement à l'encontre de ce qu'est REST, tandis que d'autres disent que toute tentative de le faire aurait pour conséquence de "souiller" les systèmes REST.

Mais admettons, à titre d'exemple, que REST soit devenu un choix d'API populaire et que tous les sites de l'univers aient commencé à exposer des points d'entrée reposants.

En effet, il me semble que l'un des avantages de REST est qu'il décompose les composants des données, ce qui devrait permettre à des clients intelligents de composer des données (et d'ajouter et d'ajuster ces données composées) à partir de plusieurs services. Mais si je ne peux pas apporter mes modifications à cette composition de données de manière atomique et isolée, alors l'utilisation de REST devient inutile.

Au fur et à mesure que le temps passe et que le besoin d'exposer sérieusement les données se fait sentir, nous allons vouloir quelque chose qui est : Simple (REST gagne sur ce point), et qui supporte un comportement transactionnel afin que nous puissions manipuler ces données de manière fiable.

J'ai lu un argument spécifique à plusieurs reprises au cours de mes recherches. Il concerne la façon dont nous sommes censés penser les transactions dans REST, et l'exemple donné est celui du panier d'achat, où l'isolation est implicite car le panier est le vôtre.

Cependant, je ne suis pas d'accord avec cet argument, tout d'abord, l'isolation d'un panier d'achat est simplement pratique, ce n'est pas une isolation de transaction. Que se passe-t-il si je fais simultanément une opération sur mon panier pendant qu'une partie de mon application lit des données à partir de celui-ci ? Je ne m'attendrais pas à ce que la partie de mon application qui lit les données voit des données qui sont "toujours en cours de transaction".

Sans parler du fait que tous les changements de données n'ont pas un modèle de transaction implicite, les transactions sur plusieurs services n'en ont certainement pas.

Il me semble que les transactions doivent avoir lieu, et qu'elles doivent avoir lieu d'une manière qui permette aux appels REST réels d'ignorer le fait (l'ajout à la charge utile du repos étant un grand non, mais l'ajout d'en-têtes étant OK).

J'ai lu quelques suggestions sur la façon dont un modèle de transaction peut être créé via REST, et certaines des spécifications écrites semblent être très récentes.

Ne devrait-il pas y avoir quelque chose de "plus" que REST afin que la nature simpliste de REST puisse être exploitée pour une manipulation solide des données (transactions "acides") ?

Si ce n'est pas le cas, devons-nous vraiment monter les enchères, et dire aux développeurs de services que s'ils veulent interagir dans un monde de données pures, ils doivent supporter quelque chose de monolithique comme soap ? ou pire encore, essayer de construire leur propre support de transaction personnalisé dans quelque chose comme REST, rendant chaque service non standard et brisant toute la puissance de REST ?

Merci d'avance pour toute réflexion.

---

Editer, ajouter un bref scénario :

Imaginez un formulaire client qui gère la création d'un album, pour des raisons de commodité sur cet album, plutôt que de demander à l'utilisateur de donner l'uri de la ressource artiste, il peut choisir dans une liste d'artistes (très probablement récupérée dans le catalogue des artistes).

Dans le scénario d'affichage, le code client comprend cela et, avant d'envoyer la demande de création de l'album, il tente d'abord de déterminer si l'artiste existe déjà et, si c'est le cas, il obtient l'uri de cet artiste, sinon il crée l'artiste et obtient l'uri de l'artiste.

Le code client continue ensuite à créer l'album, c'est le client plus intelligent que d'habitude, il n'est pas assis juste au-dessus de REST et ne poste pas "bêtement", mais a plutôt une interaction qui gère la logique REST plus pure.

Cependant, dans ce scénario, il serait bon de garantir que l'artiste n'est pas créé tant que l'album ne l'est pas, étant donné que l'artiste est créé en premier.

Ce n'est pas aussi "critique" qu'une transaction le laisserait entendre, mais cela définit un ensemble de travaux que le code client préférerait voir se dérouler en une seule opération (après tout, c'est lui qui fait en sorte que cela ressemble à une seule opération pour l'utilisateur).

Le seul conseil que j'ai vu pour ce scénario est de demander au client de prendre des mesures compensatoires en cas d'échec de la création de l'album, et d'appeler spécifiquement pour supprimer l'artiste. Mais cela semble problématique, car le client suppose que l'artiste a été isolé, aussi improbable que cela puisse être, que se passe-t-il si un autre client a déjà "vu" cet artiste, et lui attribue des droits ?

Telles sont mes préoccupations concernant les modifications de données, et bien qu'il existe certainement d'autres lacunes (qui dit que l'artiste ne pourrait pas être simplement supprimé à une date ultérieure de toute façon), ces actions ne sont PAS transparentes (c'est-à-dire que les actions ne sont pas automatisées par le client, mais quelque chose qu'un utilisateur a spécifiquement demandé).

J'espère que cela contribuera à éclairer un peu le sujet.

Answer 1

Je vais supposer que lorsque vous parlez de transactions, vous parlez d'un système distribué. Engagement biphasé protocole.

Si je comprends bien, vous essayez de comprendre comment nous pourrions utiliser REST pour effectuer des opérations qui s'étendent sur plusieurs systèmes si REST ne peut pas supporter les transactions entre des requêtes REST distinctes. Le problème est que vous partez d'une hypothèse potentiellement erronée selon laquelle nous devrions utiliser les transactions pour obtenir la cohérence. Quel prix payons-nous pour les utiliser, et quelles sont les alternatives existantes ?

Pat Helland, qui travaillait pour Amazon et qui est maintenant chez Microsoft, a écrit un article. La vie au-delà des transactions distribuées . Dans le document, la déclaration suivante est faite :

Malheureusement, les programmeurs qui s'efforcent de résoudre des objectifs commerciaux comme le commerce électronique, la gestion de la chaîne d'approvisionnement, la finance, et les applications de soins de santé doivent de plus en plus penser à sans transactions distribuées. transactions distribuées. Ils le font parce que les tentatives d'utilisation de transactions transactions distribuées sont trop fragiles et performances médiocres.

Son article explore des solutions alternatives aux transactions distribuées, qui sont évolutives et performantes.

Peut-être que REST aura du succès parce qu'il ne prend pas en charge les transactions. Voici une citation de Roy Fielding, l'homme qui a inventé le terme REST

Si vous avez besoin d'un protocole de transaction distribué, alors comment pouvez-vous dire que votre architecture est basée sur REST ? I Je ne vois tout simplement pas comment vous pouvez une situation (d'utilisation de RESTful d'application sur le client et hypermédia pour déterminer toutes les transitions transitions d'état) à la situation suivante où nécessitant un accord distribué de sémantique des transactions, dans laquelle le le client doit indiquer au serveur comment gérer ses propres ressources.

...pour l'instant je considère le "repos transaction" est un oxymore.

Ceci est tiré d'un message sur la liste REST-discuss du 9 juin 2009. Je ne peux pas fournir de lien car Yahoo groups est inutile.

Answer 2

Si vous voulez effectuer des transactions dans une application ReST, au niveau de la fonction API ReST, c'est généralement parce que vous avez encore vos lunettes d'expert en services Web.

Voyons les choses sous un autre angle.

Les googles de savon sur : Ouvrir une transaction, créer un enregistrement client, créer un enregistrement commande, valider la transaction.

ReST googles on : Demander au serveur ce qu'il doit faire. Le serveur dit "créer une ressource client", donc POST /customers. Le serveur dit "maintenant créez une commande si vous voulez", le client crée la commande en suivant le formulaire.

Dans ReST, le protocole d'application est exprimée en termes de ressources créées et manipulées, et non en termes de données qui ont des limites de transaction.

Si vous voulez avoir une transaction de longue durée qui englobe toutes ces opérations, c'est l'option serveur qui décide de l'initier, pas le client.

Vous pouvez toujours mettre en œuvre des transactions de longue durée du côté du serveur. Si vous essayez de vouloir des transactions du côté client, vous supposez que le client connaît déjà toutes les opérations qu'il va exécuter et les limites de transaction qui existent entre ces opérations. Si c'est ce que vous attendez du client, vous avez déjà renoncé à la nature hypermédia et à la liaison tardive d'une architecture de repos.

Donc, en effet, si vous ne faites pas ReST et que vous essayez d'intégrer RPC sur http, vous aurez un problème avec l'absence de transactions.

Answer 3

Je pense que la plupart des actions qui nécessitent normalement des transactions peuvent être retravaillées pour se produire sans elles.

Par exemple, le virement bancaire classique. Supposons que je veuille transférer 100 dollars du compte A au compte B :

Begin Transaction
  /Debit  A, $100  
  /Credit B, $100
Commit Transaction

Cela pourrait être retravaillé comme suit :

 /Transfer  A, B, $100  

De cette façon, le serveur peut effectuer cette opération en deux étapes, mais l'action du client est une opération unique et atomique qui a un sens logique.

Je suis sûr qu'il existe de nombreux exemples où il est plus pratique d'effectuer un ensemble d'opérations tout ou rien (et je suis curieux de voir ce que les gens peuvent proposer pour y remédier), mais je retravaille généralement les choses de cette manière.

Answer 4

Une opération REST peut lancer une transaction, effectuer plusieurs opérations sur la base de données ou d'autres opérations transactionnelles, puis effectuer un commit ou un rollback, le tout dans le cadre d'une transaction.

Ce que REST ne peut pas faire, c'est être autre chose que la racine d'une transaction. Vous ne pouvez pas lancer une transaction, puis effectuer deux opérations REST et une opération de base de données, puis les valider toutes ensemble. C'est exactement comme la situation des services web ASMX dans .NET. Ils peuvent être la racine d'une transaction, mais c'est tout. Ils ont eu du succès pendant des années, jusqu'à ce que WCF soit introduit, supportant WS-Transactions. Même aujourd'hui et en utilisant WCF, la plupart des opérations des services web n'ont pas besoin d'être transactionnelles au sens où vous l'entendez.

Answer 5

Je pense que les transactions utilisant REST sont réellement réalisables. Considérez une transaction comme une ressource que vous pouvez créer (démarrer), modifier (poster des modifications) et supprimer (valider, revenir en arrière). Les modifications apportées à la transaction n'auraient pas besoin de modifier l'état global jusqu'à ce que la transaction soit validée, et pendant la validation, vous pourriez appliquer toutes les règles de cohérence de l'état global dont vous auriez besoin. La ressource de la transaction serait, bien sûr, protégée par des règles d'autorisation.

Vous avez déjà mentionné l'illustration commune de ce concept :

J'ai lu un argument spécifique à plusieurs reprises au cours de mes recherches. Il concerne la façon dont nous sommes censés penser les transactions dans REST, et l'exemple donné est celui du panier d'achat, où l'isolation est implicite car le panier est le vôtre.

Cependant, je ne suis pas d'accord avec cet argument, tout d'abord, l'isolation d'un panier d'achat est simplement pratique, ce n'est pas une isolation de transaction. Que se passe-t-il si je fais simultanément une opération sur mon panier pendant qu'une partie de mon application lit des données à partir de celui-ci ? Je ne m'attendrais pas à ce que la partie de mon application qui lit les données voit des données qui sont "toujours en cours de transaction".

Pourquoi ne pas autoriser la visualisation de la transaction ? Tant que vous la présentez comme ce qu'elle est, une liste de changements en attente, il est utile de fournir cette fonctionnalité. Mais si vous ne vouliez pas qu'elle soit visible, vous pourriez désactiver GET sur la ressource.