Im Allgemeinen bietet RPC weitaus mehr Sprachintegration als REST. Wie Sie bereits erwähnt haben, gibt es eine Reihe von Problemen in Bezug auf Skalierung, Fehlerbehandlung, Typensicherheit usw., insbesondere wenn ein einzelnes verteiltes System mehrere Hosts umfasst, auf denen in mehreren Sprachen geschriebener Code ausgeführt wird. Nachdem ich jedoch Geschäftssysteme geschrieben habe, die RPC, REST und sogar beide gleichzeitig verwenden, habe ich festgestellt, dass es in bestimmten Fällen gute Gründe gibt, RPC vor REST zu wählen.
Hier sind die Fälle, in denen ich festgestellt habe, dass RPC besser zu mir passt:
- Enge Kupplung. Die (verteilten) Komponenten des Systems sind so konzipiert, dass sie zusammenarbeiten, und eine Änderung wird sich wahrscheinlich auf alle anderen auswirken. Es ist unwahrscheinlich, dass die Komponenten in Zukunft für die Kommunikation mit anderen Systemen angepasst werden müssen.
- Zuverlässige Kommunikation. Die Komponenten kommunizieren entweder vollständig auf demselben Host oder in einem Netzwerk, bei dem Latenzprobleme, Paketverlust usw. unwahrscheinlich sind. (Dies bedeutet jedoch weiterhin, dass Sie Ihr System für diese Fälle entwerfen müssen.)
- Einheitliche Sprache. Alle (oder fast alle) Komponenten werden in einer einzigen Sprache geschrieben. Es ist unwahrscheinlich, dass in Zukunft zusätzliche Komponenten in einer anderen Sprache hinzugefügt werden.
In Bezug auf IDL müssen Sie in einem REST-System auch Code schreiben, der die Daten in den REST-Anforderungen und -Antworten in die von Ihnen verwendete interne Datendarstellung konvertiert. IDL-Quellen (mit guten Kommentaren) können auch als Dokumentation der Schnittstelle dienen, die für eine REST-API separat geschrieben und verwaltet werden muss.
Die oben genannten drei Elemente treten häufig auf, wenn Sie eine Komponente eines größeren Systems erstellen möchten. Nach meiner Erfahrung handelt es sich bei diesen Komponenten häufig um Komponenten, bei denen ihre Subsysteme in der Lage sein müssen, unabhängig voneinander auszufallen, und nicht den vollständigen Ausfall anderer Subsysteme oder der gesamten Komponente verursachen müssen. Viele Systeme sind in Erlang geschrieben, um diese Ziele zu erreichen. In einigen Fällen ist Erlang möglicherweise die bessere Wahl, als ein System in einer anderen Sprache zu schreiben und RPC zu verwenden, um diese Vorteile zu nutzen.
Wie bei den meisten technischen Problemen gibt es keine einzige Lösung für das Problem der prozessübergreifenden Kommunikation. Sie müssen sich das System ansehen, das Sie entwerfen, und die beste Wahl für Ihren Anwendungsfall treffen.
