En général, RPC offre beaucoup plus d’intégration linguistique que REST. Comme vous l'avez mentionné, cela pose un certain nombre de problèmes d'échelle, de gestion des erreurs, de sécurité de type, etc., en particulier lorsqu'un seul système distribué implique plusieurs hôtes exécutant du code écrit dans plusieurs langues. Cependant, après avoir écrit des systèmes d’entreprise utilisant à la fois RPC, REST et même les deux simultanément, j’ai trouvé que, dans certains cas, il existait de bonnes raisons de choisir RPC plutôt que REST.
Voici les cas où j'ai trouvé que RPC convenait mieux:
- Couplage serré. Les composants (distribués) du système sont conçus pour fonctionner ensemble et leur modification aura probablement une incidence sur toutes les autres. Il est peu probable que les composants doivent être adaptés pour communiquer avec d'autres systèmes à l'avenir.
- Communication fiable. Les composants communiquent entre eux soit entièrement sur le même hôte, soit sur un réseau peu susceptible de rencontrer des problèmes de latence, de perte de paquets, etc. (Cela signifie néanmoins que vous devez concevoir votre système pour gérer ces cas.)
- Langage uniforme. Tous les composants (ou presque tous) seront écrits dans une seule langue. Il est peu probable que des composants supplémentaires écrits dans une langue différente soient ajoutés à l'avenir.
En ce qui concerne le point IDL, dans un système REST, vous devez également écrire un code qui convertit les données dans les demandes REST et les réponses à la représentation de données interne que vous utilisez. Les sources IDL (avec de bons commentaires) peuvent également servir de documentation de l'interface, qui doit être écrite et gérée séparément pour une API REST.
Les trois éléments ci-dessus apparaissent souvent lorsque vous envisagez de créer un composant d'un système plus vaste. D'après mon expérience, ces composants sont souvent ceux dont les sous-systèmes doivent pouvoir échouer indépendamment et ne pas causer la défaillance totale d'autres sous-systèmes ou du composant dans son ensemble. De nombreux systèmes sont écrits en Erlang pour atteindre également ces objectifs et, dans certains cas, Erlang peut être un meilleur choix que d'écrire un système dans une autre langue et d'utiliser RPC uniquement pour obtenir ces avantages.
Comme la plupart des problèmes d’ingénierie, il n’existe pas une solution unique au problème de la communication interprocessus. Vous devez examiner le système que vous concevez et faire le meilleur choix pour votre cas d'utilisation.
