gRPC vs. REST: Wann welches Protokoll für interne Services

1. Warum die Frage überhaupt gestellt wird

Sobald ein System aus mehreren internen Services statt einem Monolithen besteht, taucht früher oder später die Frage auf, wie diese Services untereinander kommunizieren sollen. REST über HTTP/JSON hat sich für öffentliche APIs als De-facto-Standard etabliert, weil es einfach zu verstehen, mit jedem HTTP-Client testbar und ohne Spezialwerkzeug lesbar ist. Für interne Service-zu-Service-Kommunikation, wo diese Eigenschaften weniger zählen und Performance stärker ins Gewicht fällt, wird gRPC regelmäßig als überlegene Alternative genannt.

Die Antwort ist in der Praxis kein pauschales Entweder-oder, sondern hängt von konkreten Faktoren ab: wie viele Requests pro Sekunde tatsächlich anfallen, ob Streaming gebraucht wird, wie das Team mit Protocol-Buffer-Tooling umgehen kann und wie wichtig es ist, dass jeder Entwickler mit einem einfachen curl-Aufruf gegen den Service testen kann. Dieser Artikel ordnet die relevanten Unterschiede konkret ein, statt gRPC pauschal als die modernere und damit automatisch bessere Wahl zu behandeln.

2. Die technischen Grundlagen im Vergleich

REST über HTTP/1.1 oder HTTP/2 mit JSON-Payload ist textbasiert und selbstbeschreibend: Ein Response-Body lässt sich ohne Schema lesen und verstehen. gRPC baut dagegen auf HTTP/2 als Transportschicht und Protocol Buffers als binäres Serialisierungsformat, das ein festes Schema (die .proto-Datei) voraussetzt. Ohne dieses Schema ist eine gRPC-Nachricht für einen Menschen nicht lesbar, was den entscheidenden Unterschied im täglichen Debugging-Alltag ausmacht.

Aus der Kombination von HTTP/2 und binärer Serialisierung ergibt sich der Performance-Vorteil von gRPC: kleinere Nachrichtengrößen durch Protocol Buffers statt JSON-Text, Multiplexing mehrerer Anfragen über eine einzige TCP-Verbindung durch HTTP/2, und Header-Kompression. Bei sehr hoher Request-Frequenz zwischen internen Services, etwa tausenden Aufrufen pro Sekunde, summieren sich diese Vorteile zu einer spürbar geringeren Latenz und CPU-Last gegenüber äquivalentem JSON-über-HTTP/1.1.

// order.proto — Schema-Definition fuer den gRPC-Service
syntax = "proto3";

package orders;

service OrderService {
  rpc GetOrder (GetOrderRequest) returns (Order);
  rpc StreamOrderUpdates (OrderSubscription) returns (stream OrderEvent);
}

message GetOrderRequest {
  string order_id = 1;
}

message Order {
  string id = 1;
  string status = 2;
  double total_amount = 3;
  repeated OrderItem items = 4;
}

message OrderItem {
  string sku = 1;
  int32 quantity = 2;
  double unit_price = 3;
}

3. Typsicherheit durch Protocol Buffers

Ein zentraler praktischer Vorteil von gRPC ist die automatische Codegenerierung: Aus einer .proto-Datei lassen sich Client- und Server-Stubs für PHP, Go, Python, TypeScript und viele weitere Sprachen generieren, mit vollständiger Typsicherheit auf beiden Seiten. Ein Feld, das im Schema als int32 definiert ist, kann auf Client-Seite nicht versehentlich einen String erhalten, der Compiler oder die IDE meldet den Fehler bereits vor der Ausführung.

Bei REST-APIs übernimmt diese Rolle heute meist OpenAPI mit generierten Clients, was den Typsicherheits-Abstand zu gRPC in der Praxis deutlich verkleinert hat. Der Unterschied liegt eher darin, dass das Schema bei gRPC von Anfang an verbindlicher Bestandteil des Protokolls ist, während eine OpenAPI-Spezifikation bei REST-APIs immer eine nachträgliche, freiwillige Beschreibung bleibt, die von der tatsächlichen Implementierung abweichen kann, wenn sie nicht durch Contract-Tests abgesichert wird.

4. Streaming: der Bereich, in dem REST strukturell schwächer ist

Der klarste funktionale Vorteil von gRPC liegt im nativen Support für bidirektionales Streaming: Ein Client kann einen Stream von Nachrichten an den Server senden, während er gleichzeitig einen Stream von Antworten empfängt, alles über eine einzige, langlebige HTTP/2-Verbindung. REST kennt dieses Muster nicht nativ und muss auf WebSockets, Server-Sent Events oder wiederholtes Polling ausweichen, was jeweils eigene Komplexität und eigene Infrastruktur-Anforderungen mitbringt.

Für Anwendungsfälle wie kontinuierliche Preisaktualisierungen, Live-Lagerbestandsänderungen oder Echtzeit-Log-Aggregation zwischen internen Services ist gRPC-Streaming deshalb oft die technisch sauberere Lösung. Für klassische Request-Response-Interaktionen, die den Großteil interner API-Kommunikation ausmachen, spielt dieser Vorteil dagegen keine Rolle, weil dort ohnehin kein Streaming gebraucht wird.

<?php
// PHP gRPC-Client: Stream von Order-Updates konsumieren
$client = new OrderServiceClient('order-service:50051', [
    'credentials' => ChannelCredentials::createInsecure(),
]);

$call = $client->StreamOrderUpdates(new OrderSubscription(['customer_id' => $customerId]));

foreach ($call->responses() as $event) {
    // Jede Nachricht kommt einzeln an, sobald der Server sie sendet
    echo sprintf("Order %s: %s\n", $event->getOrderId(), $event->getStatus());
}

$status = $call->getStatus();
if ($status->code !== \Grpc\STATUS_OK) {
    throw new RuntimeException("gRPC-Stream fehlgeschlagen: {$status->details}");
}

5. Debugging und Tooling-Realität im Team

Der praktische Nachteil von gRPC zeigt sich nicht in Benchmarks, sondern im Alltag: Ein REST-Endpoint lässt sich mit curl, dem Browser oder Postman ohne jede Vorbereitung testen. Für gRPC braucht es zwingend einen gRPC-fähigen Client wie grpcurl oder BloomRPC, der Zugriff auf die passende .proto-Datei hat. Für ein Team, das häufig schnell mal eben eine Anfrage von Hand absetzen will, um ein Problem einzugrenzen, ist das eine spürbare Hürde.

Auch Netzwerk-Debugging-Tools wie Browser-DevTools oder klassische HTTP-Proxys zeigen bei gRPC nur binären Datenmüll an, wo sie bei REST/JSON die vollständige, lesbare Nutzlast anzeigen würden. Teams, die viel Wert auf schnelles, werkzeugarmes Debugging legen, unterschätzen diesen Reibungsverlust häufig, bis sie ihn im produktiven Alltag tatsächlich spüren.

6. Browser-Kompatibilität und externe Konsumenten

Ein oft übersehener, aber entscheidender Punkt: Web-Browser können kein natives gRPC über HTTP/2 sprechen, weil sie keinen direkten Zugriff auf HTTP/2-Trailer-Frames erlauben, die gRPC für den Status-Code am Streamende benötigt. Für gRPC aus dem Browser braucht es zusätzlich einen Proxy wie Envoy mit gRPC-Web-Übersetzung, was zusätzliche Infrastruktur bedeutet, die eine reine REST-API nicht braucht.

Für APIs, die auch von externen Partnern, Drittanbieter-Integratoren oder direkt aus einer Single-Page-Application konsumiert werden sollen, ist REST deshalb praktisch fast immer die richtige Wahl, unabhängig von den technischen Vorzügen von gRPC für interne Kommunikation. gRPC eignet sich in erster Linie für Service-zu-Service-Kommunikation innerhalb einer Infrastruktur, die vollständig unter eigener Kontrolle steht.

7. Wie groß der Performance-Unterschied wirklich ist

Der Performance-Vorsprung von gRPC gegenüber REST/JSON ist real, aber bei niedriger bis mittlerer Request-Last oft nicht spürbar. Bei einem internen Service, der wenige hundert Requests pro Sekunde bedient, macht der Unterschied zwischen JSON-Parsing und Protocol-Buffer-Deserialisierung in der Gesamt-Latenz oft nur einen einstelligen Prozentbereich aus, weil Datenbankzugriffe und Geschäftslogik die dominanten Kostenfaktoren bleiben.

Relevant wird der Unterschied vor allem bei sehr hoher Frequenz (mehrere tausend Requests pro Sekunde), bei sehr großen Nutzlasten, oder wenn CPU-Zeit für Serialisierung/Deserialisierung tatsächlich zum Engpass wird, etwa bei ressourcenbeschränkten Umgebungen wie Edge-Computing-Knoten. Für die meisten internen Symfony-basierten Microservice-Landschaften ist die Antwort nüchterner: REST bleibt performant genug, solange die eigentlichen Datenbankzugriffe und nicht die Serialisierung den Flaschenhals bilden.

8. Hybride Architekturen: beide Protokolle gezielt kombinieren

In der Praxis schließen sich REST und gRPC nicht gegenseitig aus. Ein verbreitetes Muster ist, öffentliche und Browser-konsumierte APIs weiterhin über REST/OpenAPI anzubieten, während besonders latenzkritische, hochfrequente interne Service-zu-Service-Aufrufe gezielt auf gRPC umgestellt werden. Ein API-Gateway übernimmt dabei die Übersetzung zwischen der externen REST-Schnittstelle und den internen gRPC-Aufrufen.

Diese hybride Strategie erlaubt es, den Migrationsaufwand auf die Stellen zu konzentrieren, an denen der Performance-Gewinn tatsächlich messbar ist, statt eine komplette Systemlandschaft pauschal umzustellen. Für die meisten Teams ist das der pragmatischere Weg als eine vollständige Migration in die eine oder andere Richtung.

9. Entscheidungshilfe: Kriterien im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten Entscheidungskriterien zusammen, um im konkreten Projekt schneller zu einer begründeten Wahl zu kommen, statt sich allein an der technischen Neuheit von gRPC zu orientieren.

10. Zusammenfassung

11. FAQ: gRPC vs. REST: Das Wichtigste auf einen Blick