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 :
- Le réseau est fiable
- La latence est nulle
- La bande passante est infinie
- Le réseau est sécurisé
- La topologie ne change pas
- Il y a un administrateur
- Le coût du transport est nul
- 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
a
et ensuite b
, je récupère le résultat de a
puis 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.