Programmierung · Web · API
gRPC vs. REST
Wenn Sie die Kommunikation zwischen zwei Programmen über ein Netzwerk entwerfen, ist die moderne Weggabelung REST vs. gRPC. Beide stellen Funktionen über HTTP bereit, setzen aber auf gegensätzliche Wetten: REST bevorzugt die lesbare, universelle Einfachheit; gRPC die schnelle, typisierte, binäre Effizienz. Dieser Leitfaden vergleicht sie ehrlich nach Format, Performance, Streaming, Browser-Support und Tooling – und wann man welches wählt. (Neu bei APIs? Beginnen Sie mit Was ist eine API.)
Der grundlegende Unterschied
- REST – ein Stil der Architektur über HTTP: Ressourcen an URLs, HTTP-Verben (GET/POST/PUT/DELETE), in der Regel JSON. Lesbar, zustandslos, universell.
- gRPC – ein Framework für entfernte Prozeduraufrufe: Sie rufen Methoden auf (wie lokale Funktionen), die in einem
.proto-Vertrag definiert sind, und tauschen binäre Protocol Buffers über HTTP/2 aus.
REST ist ressourcenorientiert („hol dieses Ding ab“); gRPC ist aktionsorientiert („ruf diese Methode auf“). REST ist Text; gRPC ist binär und stark typisiert.
Performance und Transport
Die Protocol Buffers von gRPC sind kompaktes Binär, gesendet über gemultiplexte HTTP/2-Verbindungen – kleinere Nutzlasten, weniger Parsing, mehrere Aufrufe über eine Verbindung. Das JSON von REST über HTTP/1.1 ist schwerer und ausführlicher, wenngleich hochgradig optimiert und cachebar. Für den Verkehr zwischen Diensten mit hohem Volumen ist die Effizienz von gRPC real; für eine typische öffentliche API reicht REST oft aus und profitiert vom kostenlosen HTTP-Caching.
Streaming, Verträge und Codegen
gRPC unterstützt nativ bidirektionales Streaming (Client, Server und beide Richtungen), ideal für Echtzeit und hohen Durchsatz. Seine .proto-Datei ist ein strikter Vertrag, aus dem Clients und Server in vielen Sprachen generiert werden – perfekt für polyglotte Backends und um Inkompatibilitäten zur Kompilierzeit zu erkennen. REST hat keinen eingebauten Vertrag (OpenAPI/Swagger wird hinzugefügt) und das Streaming ist begrenzt (SSE/WebSockets werden hinzugefügt), aber diese Flexibilität ist auch das, was den Einstieg leicht macht.
Browser-Support und Allgegenwart
Das ist das Heimspiel von REST. Jeder Browser ruft eine REST-API über fetch auf; jede Sprache und jedes Tool versteht sie; man debuggt sie mit curl und liest das JSON. Browser sprechen kein rohes gRPC – man braucht gRPC-Web plus einen Proxy (z. B. Envoy), was bewegliche Teile hinzufügt. Wenn Ihre Web-Frontends die Hauptkonsumenten sind, ist REST (oder GraphQL) einfacher.
Ein Ort, um Ihre Dienste zu hosten
Ob REST oder gRPC – Ihre API und Ihre Microservices brauchen ein zuverlässiges Zuhause mit voller Kontrolle über Laufzeit und Netzwerk. Ein VPS oder Cloud-Server eignet sich. Infomaniak – ein Schweizer, datenschutzfreundlicher Hoster – bietet passende VPS und Cloud-Server.
Infomaniak Cloud ansehen →Affiliate-Link – er unterstützt diese kostenlosen Leitfäden.
Wie man wählt
- Nehmen Sie REST für öffentliche APIs, Browser-Clients, einfaches CRUD und wenn Lesbarkeit, Allgegenwart und HTTP-Caching zählen.
- Nehmen Sie gRPC für interne Aufrufe zwischen Diensten, bei denen Performance, niedrige Latenz, Streaming und ein strikt typisierter Vertrag zählen (Microservices, Echtzeit, polyglott).
- Beides – REST/GraphQL am Rand für Clients, gRPC zwischen internen Diensten: eine weit verbreitete Architektur.
Häufige Fragen
Was ist der Unterschied zwischen gRPC und REST?
REST ist ein Architekturstil für Web-APIs auf Basis von HTTP, der in der Regel lesbares JSON über Ressourcen-URLs austauscht. gRPC ist ein leistungsstarkes RPC-Framework, das auf HTTP/2 läuft und binäre Protocol Buffers austauscht, die durch einen strikten .proto-Vertrag definiert sind. Kurz gesagt: REST ist ressourcenorientiert, textbasiert und universell; gRPC ist aktionsorientiert (methodenbasiert), binär, typisiert und schnell. Beide lösen dasselbe Problem – Programme, die über ein Netzwerk kommunizieren – mit unterschiedlichen Kompromissen.
Ist gRPC schneller als REST?
In der Regel ja für den Verkehr zwischen Diensten. gRPC sendet kompakte binäre Protocol Buffers über gemultiplexte HTTP/2-Verbindungen: kleinere Nutzlasten, weniger Overhead als JSON über HTTP/1.1 und bidirektionales Streaming. Der Vorsprung zählt vor allem bei internen Microservices mit hohem Volumen; für eine wenig ausgelastete öffentliche API reicht REST + HTTP-Caching oft völlig aus.
Kann man gRPC in einem Browser nutzen?
Nicht direkt. Browser sprechen kein rohes gRPC, weil sie die Low-Level-HTTP/2-Steuerung, die gRPC benötigt, nicht freigeben. Man nutzt gRPC-Web mit einem Proxy (z. B. Envoy) als Brücke, was Komplexität hinzufügt und einige Funktionen einschränkt (etwa Client-Streaming). REST hingegen funktioniert nativ aus jedem Browser über fetch. Wenn Ihre API hauptsächlich von Web-Frontends konsumiert wird, ist REST (oder GraphQL) einfacher.
Wann sollte man gRPC statt REST nutzen?
Wählen Sie gRPC für die interne Kommunikation zwischen Diensten, bei der Performance, niedrige Latenz, Streaming und ein strikt typisierter Vertrag zählen – Microservices, Echtzeitdaten, polyglotte Backends. Wählen Sie REST für öffentliche APIs, Browser-Clients, einfaches Ressourcen-CRUD und wenn Lesbarkeit, Allgegenwart und kostenloses HTTP-Caching im Vordergrund stehen. Viele Systeme nutzen beides: REST/GraphQL am Rand für Clients, gRPC zwischen internen Diensten.
Fazit
REST und gRPC sind keine Rivalen, sondern Werkzeuge für unterschiedliche Aufgaben. REST gewinnt bei Universalität, Browser-Support, Lesbarkeit und Caching – die richtige Voreinstellung für öffentliche und Web-APIs. gRPC gewinnt bei Geschwindigkeit, Streaming und typisierten Verträgen – die richtige Voreinstellung für leistungsstarke interne Microservices. Wählen Sie nach Ihren Aufrufern und Ihrem Verkehr, und scheuen Sie sich nicht, beides zu nutzen.