Share
Die REST-API ist seit langem eine Säule der Webprogrammierung. In letzter Zeit hat gRPC jedoch begonnen, sein Territorium zu durchbrechen. Es stellt sich heraus, dass es dafür sehr gute Gründe gibt. In diesem Lernprogramm erfahren Sie mehr über die Besonderheiten von gRPC und den Vergleich mit REST.
Einer der größten Unterschiede zwischen REST und gRPC ist das Format der Nutzlast. REST-Nachrichten enthalten normalerweise JSON. Dies ist keine strikte Anforderung, und theoretisch können Sie alles als Antwort senden, aber in der Praxis konzentriert sich das gesamte REST-Ökosystem einschließlich Tools, Best Practices und Tutorials auf JSON. Es ist sicher zu sagen, dass REST-APIs JSON mit wenigen Ausnahmen akzeptieren und zurückgeben.
gRPC hingegen akzeptiert Protobuf-Nachrichten und gibt sie zurück. Ich werde später auf das starke Tippen eingehen, aber Protobuf ist aus Performance-Sicht ein sehr effizientes und komprimiertes Format. JSON hingegen ist ein Textformat. Sie können JSON komprimieren, verlieren jedoch den Vorteil eines Textformats, das Sie leicht erwarten können.
Vergleichen wir die von REST und gRPC verwendeten Übertragungsprotokolle. Wie bereits erwähnt, hängt REST stark von HTTP (normalerweise HTTP 1.1) und dem Request-Response-Modell ab. Auf der anderen Seite verwendet gRPC das neuere HTTP / 2-Protokoll.
Es gibt verschiedene Probleme, die HTTP 1.1 mit HTTP / 2 behebt. Hier sind die wichtigsten.
HTTP 1.0 RFC 1945 ist ein 60-Seiten-RFC. HTTP 1.1 wurde ursprünglich in RFC 2616 beschrieben, das bis zu 176 Seiten aufblähte. Später teilte die IETF sie jedoch in sechs verschiedene Dokumente auf - RFC 7230, 7231, 7232, 7233, 7234 und 7235 - mit einer noch höheren kombinierten Seitenzahl. HTTP 1.1 ermöglicht viele optionale Teile, die zu Größe und Komplexität beitragen.
Der Trend bei Webseiten besteht darin, sowohl die Gesamtgröße der Seite (durchschnittlich 1,9 MB) als auch die Anzahl der Objekte auf der Seite zu erhöhen, für die individuelle Anforderungen erforderlich sind. Da für jedes Objekt eine separate HTTP-Anforderung erforderlich ist, wird durch die Multiplikation von separaten Objekten die Belastung der Webserver erheblich erhöht und die Seitenladezeiten für Benutzer werden verringert.
HTTP 1.1 ist latenzabhängig. Für jede einzelne Anforderung ist ein TCP-Handshake erforderlich. Eine größere Anzahl von Anforderungen erfordert einen erheblichen Zeitaufwand für das Laden einer Seite. Die ständige Verbesserung der verfügbaren Bandbreite löst diese Latenzprobleme in den meisten Fällen nicht.
Die Beschränkung der Anzahl der Verbindungen zu derselben Domäne (früher nur 2, heute 6 bis 8) reduziert die Möglichkeit, mehrere Anforderungen parallel zu senden.
Mit dem HTTP-Pipelining können Sie eine Anforderung senden, während Sie auf die Antwort auf eine vorherige Anforderung warten, und so eine Warteschlange erstellen. Das führt jedoch zu anderen Problemen. Wenn Ihre Anfrage hinter einer langsamen Anfrage stecken bleibt, leidet Ihre Antwortzeit.
Es gibt andere Bedenken wie Leistung und Ressourcenstrafen beim Wechseln der Zeilen. Derzeit ist das HTTP-Pipelining nicht weit verbreitet.
HTTP / 2, das aus Googles SPDY hervorgegangen ist, verwaltet die grundlegenden Voraussetzungen und Paradigmen von HTTP:
Accentsconagua
http: // und https: // URL-SchemataDie optionalen Teile von HTTP 1.1 wurden jedoch entfernt.
Um das Verhandlungsprotokoll aufgrund des freigegebenen URL-Schemas anzusprechen, gibt es einen Upgrade-Header. Hier ist auch ein Schocker für Sie: Das HTTP / 2-Protokoll ist binär! Wenn Sie sich mit Internetprotokollen befasst haben, wissen Sie, dass Textprotokolle als König gelten, da sie für Menschen einfacher sind, manuell Fehler zu behandeln und Anforderungen zu erstellen. In der Praxis verwenden die meisten Server heutzutage ohnehin Verschlüsselung und Komprimierung. Das binäre Framing trägt wesentlich dazu bei, die Komplexität beim Umgang mit Frames in HTTP 1.1 zu reduzieren.
Die wesentliche Verbesserung von HTTP / 2 besteht jedoch darin, dass es Multiplex-Streams verwendet. Eine einzige HTTP / 2-TCP-Verbindung kann viele bidirektionale Streams unterstützen. Diese Streams können verschachtelt sein (keine Warteschlangen), und mehrere Anforderungen können gleichzeitig gesendet werden, ohne dass jeweils neue TCP-Verbindungen hergestellt werden müssen. Außerdem können Server jetzt Benachrichtigungen über die eingerichtete Verbindung an die Clients senden (HTTP / 2-Push)..
REST ist eine interessante API. Es ist sehr eng auf HTTP aufgebaut. Es verwendet nicht nur HTTP als Transportmittel, sondern umfasst alle Funktionen und bildet darüber hinaus ein konsistentes konzeptionelles Rahmenwerk. Theoretisch hört es sich gut an. In der Praxis war es sehr schwierig, REST ordnungsgemäß zu implementieren.
Verstehen Sie mich nicht falsch - REST war und ist sehr erfolgreich, aber die meisten Implementierungen halten sich nicht vollständig an die REST-Philosophie und verwenden nur einen Teil ihrer Prinzipien. Der Grund ist, dass es tatsächlich ziemlich schwierig ist, Geschäftslogik und -abläufe in der strengen REST-Welt abzubilden.
Das konzeptionelle Modell, das von gRPC verwendet wird, besteht darin, Dienste mit klaren Schnittstellen und strukturierten Nachrichten für Anforderungen und Antworten zu haben. Dieses Modell übersetzt direkt aus Programmiersprachenkonzepten wie Schnittstellen, Funktionen, Methoden und Datenstrukturen. Dadurch kann gRPC automatisch Client-Bibliotheken für Sie generieren.
REST unterstützt nur das in HTTP 1.x verfügbare Anforderungsantwortmodell. GRPC nutzt jedoch die Möglichkeiten von HTTP / 2 in vollem Umfang und ermöglicht das ständige Streaming von Informationen. Es gibt verschiedene Arten des Streamings.
Der Server sendet einen Antwortstrom zurück, nachdem er eine Clientanfragenachricht erhalten hat. Nachdem Sie alle Antworten zurückgesendet haben, werden die Statusdetails des Servers und die optionalen nachfolgenden Metadaten zurückgesendet, um auf der Serverseite abgeschlossen zu werden. Der Client wird beendet, sobald alle Antworten des Servers vorliegen.
Der Client sendet einen Stream mit mehreren Anforderungen an den Server. Der Server sendet eine einzelne Antwort zurück, in der Regel, aber nicht unbedingt, nachdem alle Anforderungen des Clients zusammen mit den Statusdetails und optional nachgestellten Metadaten empfangen wurden.
In diesem Szenario senden der Client und der Server Informationen in ziemlich freier Form (außer der Client initiiert die Sequenz). Schließlich schließt der Client die Verbindung.
Das REST-Paradigma schreibt keine Struktur für die ausgetauschte Nutzlast vor. Es ist typischerweise JSON. Verbraucher haben keinen formalen Mechanismus, um das Format von Anfragen und Antworten zu koordinieren. Der JSON muss sowohl auf der Serverseite als auch auf der Clientseite serialisiert und in die Zielprogrammiersprache konvertiert werden. Die Serialisierung ist ein weiterer Schritt in der Kette, der die Möglichkeit von Fehlern sowie Performance-Overhead einführt.
Der gRPC-Servicevertrag enthält stark typisierte Nachrichten, die automatisch von ihrer Protobuf-Darstellung in die gewünschte Programmiersprache auf dem Server und auf dem Client konvertiert werden.
JSON dagegen ist theoretisch flexibler, da Sie dynamische Daten senden können und sich nicht an eine starre Struktur halten müssen.
Die Unterstützung für gRPC im Browser ist nicht so ausgereift. GRPC wird heute hauptsächlich für interne Dienste verwendet, die nicht direkt der Welt ausgesetzt sind.
Wenn Sie einen gRPC-Dienst von einer Webanwendung oder von einer nicht von gRPC unterstützten Sprache nutzen möchten, bietet gRPC ein REST-API-Gateway an, um Ihren Dienst verfügbar zu machen. Das gRPC-Gateway-Plugin generiert einen vollwertigen REST-API-Server mit Reverse-Proxy- und Swagger-Dokumentation.
Mit diesem Ansatz verlieren Sie die meisten Vorteile von gRPC. Wenn Sie jedoch Zugriff auf einen vorhandenen Dienst benötigen, können Sie dies tun, ohne Ihren Dienst zweimal zu implementieren.
In der Welt der Mikrodienste wird gRPC sehr bald dominieren. Die Leistungsvorteile und die einfache Entwicklung sind einfach zu gut, um sie zu übersehen. Machen Sie jedoch keinen Fehler, REST wird noch lange auf sich warten lassen. Es eignet sich immer noch für öffentlich zugängliche APIs und aus Gründen der Abwärtskompatibilität.
