API: REST vs. GraphQL vs. gRPC
Die Wahl zwischen REST, GraphQL und gRPC hängt von der Architektur, den Clients und den Anforderungen an Performance, Flexibilität und Wartbarkeit ab.
Kompakte Beschreibung
REST, GraphQL und gRPC sind drei gängige Ansätze für APIs, die sich in Protokoll, Nutzungsmodell und Architektur unterscheiden. REST ist ein ressourcenorientierter Architekturstil auf Basis von HTTP, der sich durch Einfachheit und universelle Unterstützung auszeichnet. GraphQL ist eine Abfragesprache, die Clients erlaubt, exakt die Daten anzufordern, die sie benötigen. gRPC ist ein Framework für Remote Procedure Calls, das auf HTTP/2 und Protocol Buffers setzt und besonders für interne Microservices performant ist. Die richtige Wahl hängt von der Zielgruppe, der Netzwerktopologie, den Datenstrukturen und den Anforderungen an Latenz und Skalierbarkeit ab. In vielen Systemen werden die Stile auch kombiniert.
Wichtige Komponenten
REST als Architekturstil
REST definiert keine Technologie, sondern Prinzipien. Zustandslosigkeit, Ressourcenorientierung, einheitliche Schnittstellen und Selbstbeschreibung sind zentrale Eigenschaften. REST ist leicht zu erlernen, wird von fast allen Tools und Frameworks unterstützt und ist besonders gut für öffentliche und browserbasierte APIs geeignet.
GraphQL als Abfragesprache
GraphQL gibt dem Client die Kontrolle über die Daten. Ein zentrales Schema definiert Typen, Queries, Mutations und Subscriptions. Der Client fragt gezielt Felder ab, der Server löst die Query mit Resolvern auf. GraphQL ist besonders wertvoll, wenn viele unterschiedliche Clients unterschiedliche Datenansichten benötigen.
gRPC als RPC-Framework
gRPC abstrahiert Netzwerkaufrufe als Methodenaufrufe. Services werden in Protocol Buffer Dateien definiert, Client und Server werden automatisch generiert. gRPC ist binär, typisiert und unterstützt Streaming. Es wird vor allem in Cloud-native Umgebungen und internen Microservices eingesetzt.
Entscheidungskriterien
Bei der Wahl eines API-Stils solltest Du folgende Kriterien betrachten:
- Zielgruppe: Externe Nutzer profitieren von REST, interne Services von gRPC, komplexe Frontends von GraphQL.
- Performance: gRPC ist am effizientesten, gefolgt von REST, GraphQL kann je nach Query teuer sein.
- Flexibilität: GraphQL ist am flexibelsten, REST am standardisiertesten, gRPC am strengsten typisiert.
- Wartbarkeit: REST und gRPC sind leicht zu versionieren, GraphQL erfordert sorgfältige Schema-Evolution.
- Tooling: REST hat die größte Tool-Unterstützung, GraphQL bietet gute Entwicklerwerkzeuge, gRPC benötigt spezifische Bibliotheken.
Browserkompatibilität
REST wird von allen Browsern und Clients nativ unterstützt. GraphQL läuft über HTTP und wird von modernen JavaScript-Frameworks gut unterstützt. gRPC ist im Browser nicht nativ nutzbar, es gibt aber gRPC-Web als Lösung für Webanwendungen.
Netzwerkumgebung
In offenen Netzwerken und über das Internet ist REST einfacher zugänglich und firewallfreundlicher. In internen Netzwerken oder Kubernetes-Clustern kann gRPC seine Performance-Vorteile ausspielen. GraphQL wird oft als Gateway- oder Aggregationschicht eingesetzt.
Datenmodell und Abfragekomplexität
REST eignet sich für relativ flache Ressourcenhierarchien. GraphQL ist ideal für stark vernetzte Daten, bei denen Clients gezielt Beziehungen abfragen. gRPC ist gut für klare, prozedurale Operationen und strukturierte Nachrichten.
Versionierung und Evolution
REST verwendet meist URI oder Header Versioning. GraphQL arbeitet mit Schema Evolution und Deprecation. gRPC nutzt semantische Versionierung und Protobuf-Feldnummern. Jeder Stil hat eigene Strategien für Änderungen ohne Client-Bruch.
Sicherheit
REST nutzt gängige Standards wie OAuth, JWT und TLS. GraphQL benötigt zusätzlich Schutz vor komplexen Queries und Autorisierung auf Feldebene. gRPC setzt auf TLS und kann Interceptors für Authentifizierung und Logging verwenden.
Kombinierte Architektur
In der Praxis werden REST, GraphQL und gRPC oft kombiniert. Ein typisches Muster ist: öffentliche REST-API für Partner, GraphQL-Gateway für Web- und Mobile-Clients, gRPC für interne Servicekommunikation.
Praxisbeispiel
Ein Unternehmen betreibt eine E-Commerce-Plattform mit mehreren Schnittstellen:
Externe Partner-API mit REST:
GET /api/v1/orders/12345
Authorization: Bearer partner-token
Frontend mit GraphQL:
query OrderDetails($id: ID!) {
order(id: $id) {
status
total
customer { name email }
items { product { name } quantity price }
}
}
Interne Services mit gRPC:
service OrderService {
rpc UpdateOrderStatus (StatusUpdateRequest) returns (StatusUpdateResponse);
}
message StatusUpdateRequest {
string orderId = 1;
string status = 2;
}
message StatusUpdateResponse {
bool success = 1;
}
Diese Kombination nutzt die Stärken jedes Stils: REST für einfache externe Integration, GraphQL für flexible Frontend-Abfragen und gRPC für schnelle, zuverlässige interne Kommunikation.
FAQ: REST vs. GraphQL vs. gRPC
1. Wann sollte man REST verwenden?
2. Wann sollte man GraphQL verwenden?
3. Wann sollte man gRPC verwenden?
4. Ist GraphQL immer besser als REST?
5. Ist gRPC für öffentliche APIs geeignet?
6. Was ist ein gRPC-Web Gateway?
7. Was sind Persisted Queries?
8. Wie wählt man den richtigen API-Stil?
9. Was ist ein API Gateway?
10. Kann man GraphQL vor ein REST Backend setzen?
11. Was ist eine API-Strategie?
12. Welche Nachteile hat GraphQL?
13. Welche Nachteile hat gRPC?
14. Was ist eine Schema-First Strategie?
15. Welcher API-Stil ist für Anfänger am besten?
Weiter im API Lernpfad
Der nächste Artikel im API Lernpfad behandelt OAuth 2.0 Grundlagen: Authorization Code Flows und Access Token Implementation — der Industriestandard für delegierte Autorisierung mit allen wichtigen Flows.
Quellen
Buchempfehlungen zur API-Entwicklung
Wenn Du Dich weiter mit REST, GraphQL, gRPC und API-Architektur beschäftigen möchtest, empfehlen wir Dir die folgenden Bücher:
API-Entwicklung
Bücher über API-Design, REST, GraphQL, OpenAPI und API-Architektur
REST und HTTP: Entwicklung und Integration nach REST-Prinzipien von Stefan Tilkov
Bei Amazon ansehenAffiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.
API-Design: Praxishandbuch für Java- und Webservice-Entwickler
Bei Amazon ansehenAffiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.
Microservices: Grundlagen flexibler Softwarearchitekturen von Eberhard Wolff
Bei Amazon ansehenAffiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.






