Pourquoi REST est-il couramment utilisé à la place des mécanismes de type RPC dans les applications Web?

J'ai commencé très récemment dans une entreprise qui utilise un cadre personnalisé plutôt inhabituel pour leurs applications Web, au moins par rapport aux cadres d'applications Web typiques que je connais. Au lieu d'un service Web RESTful, un mécanisme RPC est utilisé pour communiquer avec le serveur.

La communication avec le serveur ressemble à un simple appel de fonction, mais la fonction est exécutée sur le serveur, pas sur le client. Côté serveur, il existe un moyen de définir les fonctions que le client peut appeler. Les détails de la façon dont cela est traduit en requêtes http sont complètement résumés.

Je ne l'utilise que depuis peu de temps maintenant, mais cela semble assez pratique. Mais je me demande quels sont les inconvénients de cette approche qui me manquent. Tout le monde semble le faire différemment, ce qui est généralement un signe pour moi que je fais peut-être quelque chose de stupide ou de brillant, avec des chances beaucoup plus élevées pour le premier.

REST a été conçu pour le Web et le Web a été conçu pour REST. Les deux vont juste ensemble. Les styles architecturaux et la conception d'architectures logicielles en réseau de Roy Fielding en 2000 ont défini et introduit le terme REST , et il existe une interaction significative entre le Web et REST: Roy Fielding a travaillé sur HTTP / 1.1, dont il est le principal auteur, et il a utilisé ce qu'il y a appris pour décrire REST dans sa thèse.

Ainsi, la raison simple pour laquelle le Web et REST vont si bien ensemble est que la définition de REST a été extraite de la façon dont le Web fonctionne, et le Web est une implémentation de REST.

C'est pourquoi REST convient parfaitement aux services Web et aux applications Web: parce que vous faites simplement les mêmes choses qui ont déjà fait leurs preuves sur le Web «humain» et que vous les appliquez au Web «machine».

Le gros problème avec RPC (en fonction de l' implémentation exacte ) réside essentiellement dans les sophismes du calcul distribué , qui sont expliqués plus en détail dans ce livre blanc d'Arnon Rotem-Gal-Oz :

1. Le réseau est fiable
2. La latence est nulle
3. La bande passante est infinie
4. Le réseau est sécurisé
5. La topologie ne change pas
6. Il y a un administrateur
7. Le coût du transport est nul
8. Le réseau est homogène

Ce sont toutes des hypothèses que les nouveaux arrivants font généralement lorsqu'ils commencent à créer des systèmes distribués. Bien sûr, tous sont faux. Et vous devez tous les prendre en compte lors de la création de systèmes distribués.

Le problème avec de nombreuses implémentations RPC est qu'elles essaient de faire ressembler les appels distants aux appels locaux. Mais ils ne se ressemblent pas:

• un appel local n'échoue jamais; le sous - programme que vous avez appelé peut échouer, mais l'appel lui - même ne le fait jamais - un appel distant peut se perdre sur le réseau
• un appel local est instantané; le sous - programme que vous avez appelé peut fonctionner pendant une longue période (ou même pour toujours s'il est bloqué dans une boucle infinie), mais l'appel lui - même ne prend pas de temps du tout (enfin, une poignée d'instructions du processeur au plus, moins si l'appel est en ligne, mais c'est très rapide) - un appel à distance peut rester bloqué sur le réseau pendant une longue période
• si le sous-programme revient normalement, le résultat revient toujours - avec un appel à distance, le résultat peut être perdu sur le réseau
• les retours sont instantanés - les résultats à distance peuvent voyager sur le réseau pendant une longue période
• si j'appelle une sous-routine une fois, elle s'exécutera exactement une fois - un appel distant peut être perdu sur le réseau, ou dupliqué de sorte que la routine distante peut s'exécuter entre 0 et un nombre illimité de fois
• Je récupère exactement un résultat - un résultat distant peut être perdu ou dupliqué, vous pouvez donc obtenir le résultat 0 fois ou plus
• si j'appelle un sous-programme deux fois, j'obtiens deux résultats et j'obtiens le résultat du premier appel avant le résultat du deuxième appel - vous pouvez probablement le deviner maintenant: avec RPC, vous ne pouvez obtenir aucun résultat, ou seulement le premier , ou seulement la seconde, ou la seconde avant la première, ou la première peut être perdue et vous obtenez la seconde deux fois, ou l'inverse, et ainsi de suite…
• si j'appelle aet ensuite b, je récupère le résultat de apuis le résultat de b - ceci est juste une version plus générale du point précédent, avec RPC, vous pouvez obtenir l'une des deux réponses 0 fois ou plus dans n'importe quel ordre

Vous devrez faire face à tout ce qui précède pour un appel à distance. Mais si votre infrastructure rend les appels distants indiscernables des appels locaux, vous ne pouvez pas , car vous ne savez pas lesquels sont les appels distants. Le framework peut essayer de gérer tout cela pour vous, mais le problème est: le framework n'en sait pas autant sur votre système que vous. Il ne sait pas s'il y a des appels où cela n'a pas d'importance si l'un se perd de temps en temps. Donc, le cadre doit être très défensif, et cela coûte cher en termes de latence et de bande passante.

D'autant plus que le cadre ne peut en fait pas vous protéger. Le théorème CAP dit qu'un système distribué ne peut pas être cohérent, disponible et tolérant aux partitions en même temps; plus précisément, il dit qu'une fois qu'une partition se produit, le système ne peut pas continuer à être à la fois cohérent et disponible, il doit en choisir un (contrairement à la croyance populaire, le théorème ne dit pas que vous ne pouvez pas avoir les trois, lorsque le système est en marche) normalement, vous pouvez avoir les trois; mais une fois que vous avez une partition, vous devez choisir l'une des deux autres). Le théorème PACELC étend le théorème CAP en montrant que même lorsque le système fonctionne, vous devez faire un compromis entre latence et cohérence.

Ce sont des compromis importants que le cadre ne peut pratiquement pas vous protéger, car ils sont spécifiques au domaine et importants pour la conception de base.

Cela contraste avec une approche comme Erlang de qui fait le travail: en Erlang, tous les envois de messages sont traités comme à distance, même si elles sont locales. Cela signifie que vous êtes toujours prêt à faire face à tous les problèmes ci-dessus (et bien d'autres). Pour les processus locaux, ceux - ci posent cependant un peu de surcharge. Afin d'aider à cela, il existe de nombreux outils, cadres, bibliothèques, modèles et idiomes pour gérer la gestion et la gestion des erreurs.

Vous n'avez pas décrit comment votre framework RPC fonctionne en particulier, et quel langage ou bibliothèques vous utilisez, mais j'ai une forte suspicion qu'il appartient au premier type "faire semblant que le réseau n'existe pas". Celles-ci ne fonctionnent tout simplement pas. Il est correct de supprimer la distinction entre les appels locaux et distants en traitant tout comme un appel distant . Le faire dans l'autre sens trop abstrait: le réseau fait partie de votre système, si vous l'abstenez, vous enlevez quelque chose que vous devez réellement savoir.

Maintenant, que vous deviez utiliser spécifiquement REST ou non, c'est une question entièrement différente. Comme je l' ai expliqué plus haut, le web a été conçu pour le repos et de repos a été conçu pour le web, de sorte que les deux font du sens ensemble, mais vous pouvez utiliser d' autres styles architecturaux, si vous voulez. Mais au moins une partie de votre question portait sur "pourquoi pas RPC", et j'ai exposé les raisons ci-dessus, plus précisément j'ai expliqué pourquoi le type de RPC que je soupçonne d'utiliser peut vous causer des ennuis.

Il y a déjà plusieurs bonnes idées dans les commentaires, que je vais répéter ici:

1. RPC est généralement spécifique à la technologie.
2. Ce qui intéresse principalement les développeurs, c'est JSON, pas REST.

JSON a de très belles qualités. Il est simple, facile à lire pour un humain, facile à analyser pour un ordinateur, et Javascript le reconnaît instantanément nativement (c'est, vous savez, la notation d'objet Javascript ).

Si vous êtes prêt à renoncer à des contraintes comme REST, vous pouvez faire presque tout ce que vous voulez avec JSON, y compris les appels de procédure à distance. Tout ce que vous avez à faire est d'établir un protocole adapté. En fait, un tel protocole existe déjà: JSON-RPC.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

RPC et REST ne sont que des approches différentes avec des avantages et des inconvénients et les deux ont une valeur en fonction du contexte. REST est mieux décrit pour fonctionner avec les ressources, alors que RPC est plus sur les actions. Les clients RPC sont étroitement associés à l'implémentation de services de plusieurs manières et il devient très difficile de modifier l'implémentation de services sans casser les clients.