Irgendwann steht jedes Integrationsprojekt vor der Frage: REST oder GraphQL? Die Debatte wird oft ideologisch geführt — dabei ist die Antwort fast immer eine Architekturfrage, keine Glaubensfrage. Beide Ansätze lösen dasselbe Problem auf verschiedene Weise, und beide haben Stellen, an denen sie teuer werden.
Der Kernunterschied in einem Absatz
REST modelliert Ressourcen: Jede Entität hat eine URL, der Server bestimmt die Antwortstruktur, HTTP-Verben und Statuscodes tragen die Semantik. GraphQL modelliert Abfragen: Es gibt einen Endpunkt, der Client beschreibt exakt, welche Felder er braucht, der Server liefert genau diese Struktur zurück. REST sagt „hier sind meine Ressourcen", GraphQL sagt „frag, was du brauchst".
Wo GraphQL glänzt
- Viele Clients, verschiedene Datenbedürfnisse: Mobile App braucht drei Felder, Dashboard braucht dreißig — mit GraphQL definiert das jeder Client selbst, ohne dass das Backend zehn Spezial-Endpunkte pflegt.
- Verschachtelte Daten: Kunde mit Aufträgen mit Positionen in einem Request statt drei Roundtrips. Das Over- und Underfetching-Problem von REST verschwindet.
- Schnelle Frontend-Iteration: Das typisierte Schema ist Vertrag und Dokumentation zugleich; Frontend-Teams arbeiten ohne Backend-Ticket weiter.
Wo REST die bessere Wahl bleibt
- Öffentliche APIs und Integrationen: Jeder Entwickler versteht REST sofort; Caching über HTTP (CDN, ETags) funktioniert ohne Zusatzaufwand.
- Einfache, stabile Datenmodelle: Wer im Wesentlichen CRUD auf klar geschnittenen Ressourcen macht, kauft sich mit GraphQL Komplexität ohne Gegenwert.
- Datei-Uploads, Webhooks, simple Machine-to-Machine-Kommunikation: REST bleibt hier der pragmatische Standard.
Faustregel: GraphQL lohnt sich, wenn viele unterschiedliche Clients flexibel auf ein komplexes Datenmodell zugreifen. Für stabile Ressourcen-APIs und Integrationen bleibt REST erste Wahl.
Die versteckten Kosten von GraphQL
Der Preis für die Flexibilität liegt im Betrieb. Caching muss auf Anwendungsebene gelöst werden, weil alles über einen Endpunkt läuft. Beliebig tiefe Abfragen können die Datenbank in die Knie zwingen — Query-Depth-Limits und Kosten-Analyse sind Pflicht, sonst wird die API zur Self-Service-Denial-of-Service-Fläche. Das N+1-Problem verlangt DataLoader-Patterns, Monitoring braucht spezialisierte Werkzeuge, und Fehlersemantik läuft an HTTP-Statuscodes vorbei. Nichts davon ist unlösbar — aber es ist Engineering-Aufwand, den ein REST-Setup schlicht nicht hat.
Der pragmatische Mittelweg
In der Praxis fahren viele Systeme zweigleisig: REST für öffentliche Schnittstellen, Webhooks und einfache Integrationen; GraphQL intern als Aggregationsschicht für die eigenen Frontends, oft als Backend-for-Frontend vor mehreren Microservices. Auch der umgekehrte Weg ist legitim: erst REST, und GraphQL erst dann einführen, wenn die Zahl der Spezial-Endpunkte schmerzt. Wichtig ist nur, die Entscheidung bewusst zu treffen und zu dokumentieren — nicht, weil ein Framework es gerade vorgibt.
Entscheidungsfragen für Ihr Projekt
- Wie viele verschiedene Client-Typen greifen auf die Daten zu?
- Wie tief verschachtelt sind typische Abfragen wirklich?
- Wer konsumiert die API — eigene Teams oder externe Partner?
- Gibt es Kapazität, Query-Limits, Caching und Monitoring für GraphQL sauber zu betreiben?
Wie man Schnittstellen unabhängig vom Stil sauber weiterentwickelt, zeigt der Beitrag zur API-Versionierung ohne Bruch.