it-swarm.com.de

REST vs gRPC: Wann soll ich eine über die andere wählen?

Ich sehe immer mehr Softwareunternehmen, die gRPC in ihren serviceorientierten Architekturen verwenden, aber die Leute verwenden immer noch REST. In welchen Anwendungsfällen ist die Verwendung von gRPC sinnvoll, und wann ist die Verwendung von REST für die Kommunikation zwischen Diensten sinnvoll?

Interessanterweise bin ich auf Open-Source-Projekte gestoßen, die sowohl REST als auch gRPC verwenden. Beispielsweise setzen Kubernetes und Docker Swarm gRPC zu einem gewissen Grad für die Cluster-Koordination ein, stellen aber auch REST APIs für die Schnittstelle mit Master-/Leader-Knoten. Warum nicht gRPC nach oben und unten verwenden?

25
nmurthy

Bei richtiger Ausführung verbessert REST die langfristige Entwicklungsfähigkeit und Skalierbarkeit auf Kosten der Leistung und der zusätzlichen Komplexität. REST ist ideal für Dienste, die unabhängig voneinander entwickelt und verwaltet werden müssen, z. B. das Web selbst. Client und Server können lose gekoppelt werden und sich ändern, ohne sich gegenseitig zu beschädigen.

RPC-Dienste können einfacher und leistungsfähiger sein, auf Kosten von Flexibilität und Unabhängigkeit. RPC-Dienste sind ideal für Situationen, in denen Client und Server eng miteinander verbunden sind und denselben Entwicklungszyklus durchlaufen.

Die meisten sogenannten REST -Dienste folgen jedoch überhaupt nicht wirklich REST, da REST nur ein Schlagwort für jede Art von HTTP-API wurde. Tatsächlich sind die meisten REST APIs so eng gekoppelt, dass sie keinen Vorteil gegenüber einem RPC-Entwurf bieten.

In Anbetracht dessen sind meine etwas zynischen Antworten auf Ihre Frage:

  1. Einige Leute übernehmen gRPC aus dem gleichen Grund, aus dem sie REST vor einigen Jahren übernommen haben: Design-by-Buzzword.

  2. Viele Leute erkennen, dass die Art und Weise, wie sie REST implementieren, sowieso auf RPC hinausläuft. Warum also nicht ein standardisiertes RPC-Framework verwenden und es korrekt implementieren, anstatt auf schlechten REST Implementierungen zu bestehen?

  3. REST ist eine Lösung für Probleme, die in Projekten auftreten, die mehrere Organisationen umfassen und langfristige Ziele verfolgen. Vielleicht stellen die Leute fest, dass sie REST nicht wirklich brauchen und suchen nach besseren Optionen.

23
Pedro Werneck

Abhängig von der zukünftigen Roadmap der gRPC werden die Leute weiterhin zu ihr migrieren und REST (über HTTP) "ruhig" lassen.

gRPC ist in vielerlei Hinsicht praktischer :

  • Normalerweise schnell (wie superschnell)
  • (Fast) Keine "Design-Dichotomie" - was ist der richtige Endpunkt, was ist das richtige HTTP-Verb, etc.
  • Sich nicht mit der chaotischen Eingabe-/Antwort-Serialisierung befassen, wie gRPC sich mit der Serialisierung befasst - effizientere Datencodierung und HTTP/2, was die Dinge mit Multiplex beschleunigt Anfragen über eine einzelne Verbindung und Header-Komprimierung
  • Definieren/Deklarieren Sie Ihre Eingabe/Antwort und generieren Sie zuverlässige Clients für verschiedene Sprachen (natürlich diejenigen, die "unterstützt" werden, dies ist ein RIESIGER Vorteil).
  • Formalisierter Satz von Fehlern - dies ist umstritten, aber bisher sind sie direkter auf API-Anwendungsfälle anwendbar als auf die HTTP-Statuscodes

In jedem Fall müssen Sie sich auch mit allen gRPC-Problemen auseinandersetzen, da nichts auf dieser Welt unfehlbar ist, aber es "sieht besser aus" als REST - und hat das tatsächlich bewiesen.

Ich denke, Sie können das Beste aus beiden Welten haben. In jedem Fall folgt gRPC weitgehend der HTTP-Semantik (über HTTP/2), lässt jedoch explizit Vollduplex-Streaming zu, was von den typischen REST Konventionen abweicht, da es statische verwendet Pfade aus Leistungsgründen während der Anrufverteilung, da Aufrufparameter aus Pfaden analysiert werden - Abfrageparameter und Nutzlastkörper erhöhen die Latenz und Komplexität.

9
x80486

Das Versprechen von REST war schon immer ein einheitliches Interface . Ein idealer REST Client wäre in der Lage, mit einer Vielzahl von zu sprechen REST-fähige Ressourcen, auch solche, die zum Zeitpunkt der Codierung des Clients nicht vorhanden waren.

Leider hat sich dieses Ideal bis auf den ursprünglichen Fall von REST, das World Wide Web der für Menschen lesbaren Dokumente, nie wirklich verwirklicht.

Zu diesem Zeitpunkt sind die meisten Schnittstellen, die sich "RESTful" nennen, eine Art Barock-RPC, bei dem Anforderungs- und Antwortdaten über Methoden, Abfragezeichenfolgen, Header, Statuscodes, Nutzdaten in verschiedenen fragilen Formaten verschmiert werden.

Der größte Teil der Einheitlichkeit der heutigen "RESTful" -Schnittstellen liegt in den Köpfen der Entwickler. Sie "wissen", dass POST /orders/ wird wahrscheinlich eine neue Bestellung hinzufügen. Dennoch müssen sie ihre Kunden so programmieren, dass sie wissen, dass sie bei jeder API, mit der sie sprechen, häufig viele Fehler machen.

Dennoch gibt es eine gewisse Einheitlichkeit, die im Code tatsächlich nützlich sein kann. Wenn Sie beispielsweise über eine "RESTful" -API verfügen, können Sie diese häufig fast kostenlos um eine transparente, fein abstimmbare Caching-Ebene erweitern. Dies ist möglich, weil (semantisch korrekte) HTTP-Nachrichten bereits alle für die Zwischenspeicherung erforderlichen standardisierten Informationen enthalten: Anforderungsmethode, URL, Statuscode, Cache-Control, Vary und all das. In gRPC müssen Sie Ihr eigenes Caching ausführen.

Der eigentliche Grund für die derzeitige Dominanz von „REST“ sind jedoch nicht diese geringfügigen Erschwernisse. Es ist wirklich nur der Erfolg des World Wide Web. Irgendwann in der Geschichte stellte sich heraus, dass jeder schon hatte einen performanten, flexiblen HTTP-Server (um seine Website zu bedienen) und einen soliden HTTP-Client (um diese Website anzuzeigen) hatte, also als die Leute begannen Durch das Hinzufügen von maschinenlesbaren Ressourcen war es einfacher und billiger, dieselben HTTP-Methoden zu verwenden. Sie verwendeten HTTP-Methoden sowie Header und Statuscodes, da dies von ihren Webservern bereits verstanden und protokolliert wurde. Tools wie PHP ermöglichten es ihnen, dies ohne zusätzlichen Aufwand für die Bereitstellung auf ihren regulären Websites zu tun.

Wenn für Sie die Einheitlichkeit und die Ausrichtung auf das World Wide Web nicht wichtig sind, ist RPC eine bewährte architektonische Wahl, und gRPC ist eine solide Implementierung, die Ihnen einige Probleme ersparen kann, wie ɐuıɥɔɐɯ erläutert.

9
Vasiliy Faronov