REST API vs GraphQL: Wann welche Architektur Sinn macht

REST oder GraphQL. Die Diskussion klingt nach einer Religionsfrage unter Entwicklern, ist aber eine ganz handfeste Architekturentscheidung mit Folgen für Kosten, Performance und Wartbarkeit. Wer hier falsch wählt, baut sich entweder ein überdimensioniertes System für eine simple Anwendung oder kämpft Jahre später mit einem REST-Wildwuchs, der bei jeder Frontend-Änderung explodiert.

Die ehrliche Antwort vorweg: Für die meisten mittelständischen Projekte ist REST immer noch die richtige Wahl. Trotz aller Hypes. Die Frage ist nicht, was moderner klingt, sondern was zum Problem passt.

Was REST und GraphQL eigentlich machen

REST ist seit Anfang der 2000er der Standard für Web-APIs. Jede Ressource bekommt eine URL, und du sprichst sie mit den klassischen HTTP-Verben an: GET zum Lesen, POST zum Erstellen, PUT oder PATCH zum Ändern, DELETE zum Löschen. Klar, vorhersagbar, leicht zu testen. Browser, Caches und Monitoring-Tools verstehen REST seit Jahrzehnten.

GraphQL kam 2015 von Facebook auf den Markt und löst ein konkretes Problem: Bei komplexen Frontends muss man oft fünf REST-Endpoints hintereinander aufrufen, um eine einzige Ansicht zu bauen. GraphQL ändert das. Das Frontend stellt eine einzige Anfrage, beschreibt darin genau, welche Felder es braucht, und bekommt exakt diese Daten zurück. Nichts zu wenig, nichts zu viel.

Klingt nach Allheilmittel. Ist es nicht. Wer GraphQL einsetzt, kauft sich neue Probleme ein: Caching wird komplexer, Sicherheits-Schichten brauchen mehr Aufmerksamkeit, und das Monitoring funktioniert nicht mehr nach den bekannten REST-Mustern.

Wie GraphQL in der Praxis eingesetzt wird

Wer sich Branchen-Reports zu API-Architekturen ansieht, findet immer wieder dasselbe Muster: REST dominiert nach wie vor, GraphQL kommt fast nie als Ersatz, sondern als zusätzliche Schicht für spezifische Anwendungsfälle. Wer GraphQL einführt, hat in der Regel weiterhin REST-APIs im System. Hybride Architekturen sind die Norm, nicht die Ausnahme.

Das ist die wichtigste Beobachtung in der ganzen Debatte. Wer GraphQL einführt, weil er REST vollständig ablösen will, kann sich auf einen schmerzhaften Pfad einstellen. Wer GraphQL als gezielte Ergänzung für ein konkretes Frontend-Problem einsetzt, fährt deutlich besser.

Bei der Performance gewinnt mal die eine, mal die andere Seite. GraphQL spart spürbar Datenvolumen im Response, weil das Frontend nur anfordert, was es braucht. Dafür ist die Server-seitige Verarbeitung komplexer und der Caching-Mechanismus weniger effizient. REST ist im einfachen GET-Szenario kaum zu schlagen, weil HTTP-Caches und CDNs nativ unterstützt werden. Im Schnitt gleicht sich das aus, der konkrete Use-Case entscheidet, wer vorne liegt.

Wann REST die richtige Wahl ist

Du baust eine API für ein klassisches Backend mit überschaubarer Anzahl an Entitäten. Kunden, Produkte, Bestellungen, Rechnungen. Du weißt heute schon, wer die API nutzt: ein internes Frontend, vielleicht eine Mobile App, ein paar Drittsysteme über Schnittstellen.

Du brauchst öffentliche Endpoints, die andere Entwickler nutzen sollen. REST kann jeder lesen, jeder Drittanbieter hat damit gearbeitet, jedes Tool unterstützt es. Stripe und Twilio bieten ihre öffentlichen APIs nicht zufällig immer noch primär als REST an, GitHub stellt beides bereit.

Caching ist dir wichtig. Wenn dein API-Traffic zu einem großen Teil aus Leseanfragen besteht, die sich gut cachen lassen, ist REST mit klassischem HTTP-Caching schneller und billiger als jede GraphQL-Lösung mit persistierten Queries.

Dein Team hat keine GraphQL-Erfahrung. Das ist kein Detail. Eine GraphQL-Implementierung verlangt von Backend-Entwicklern andere Denkmuster, von DevOps andere Monitoring-Tools, von Security-Verantwortlichen ein anderes Threat-Modell. Wer die Lernkurve unterschätzt, baut sich eine API, die niemand außer dem ursprünglichen Entwickler wirklich versteht.

Wann GraphQL den Aufwand rechtfertigt

Du hast ein Frontend mit vielen Ansichten, die unterschiedliche Schnitte derselben Daten brauchen. Ein Dashboard hier, eine Detailansicht dort, mobile Karten mit reduziertem Datenumfang. Jede Ansicht würde mit REST mehrere Aufrufe oder spezielle Endpoints benötigen.

Du integrierst mehrere Datenquellen, die das Frontend nicht selbst orchestrieren soll. Das ist der klassische Backend-for-Frontend-Fall. GraphQL kann als Aggregations-Schicht über mehreren REST-Services liegen und das Frontend von der Komplexität abschirmen.

Du hast mehrere Frontend-Teams, die unabhängig arbeiten wollen. Bei REST muss der Backend-Entwickler für jeden neuen Datenschnitt einen neuen Endpoint bauen oder bestehende anpassen. Bei GraphQL definiert das Frontend selbst, was es braucht, ohne dass das Backend für jeden Use-Case erweitert werden muss. Das spart Koordinationsaufwand, wenn drei Teams gleichzeitig an unterschiedlichen Features arbeiten.

Du hast eine native Mobile App mit knappem Datenvolumen. Über LTE oder 5G ist jedes Kilobyte spürbar. GraphQL spart hier echte Ladezeit, weil nicht ganze Objekte über das Netz wandern, sondern nur die wirklich genutzten Felder.

Die Fehler, die wir in der Praxis sehen

Erstens: GraphQL einführen, weil ein anderes Team es macht. Architekturentscheidungen, die mit „die Kollegen bei Firma X nutzen das auch” begründet sind, gehen meistens schief. Die Anforderungen sind selten vergleichbar, und das fremde Team hat oft schon Probleme, die noch nicht sichtbar sind.

Zweitens: REST ohne Disziplin. Wer GraphQL als Ausweg aus einer schlechten REST-Implementierung sieht, löst das eigentliche Problem nicht. Eine schlecht entworfene API wird nicht besser, nur weil sie auf einer neuen Technologie läuft. Wer REST nicht sauber strukturiert, kriegt GraphQL erst recht nicht in den Griff.

Drittens: GraphQL ohne Caching-Konzept. REST-Caches funktionieren von alleine, GraphQL nicht. Wer ohne Apollo Server, ohne persistierte Queries und ohne CDN-Konzept startet, hat unter Last regelmäßig schlechtere Performance als mit der alten REST-API.

Viertens: Sicherheits-Lücken durch zu offene Schemas. GraphQL lässt das Frontend tief in die Datenbankstruktur greifen, wenn man nicht aufpasst. Query-Komplexitäts-Limits, Tiefenbegrenzungen und feingranulare Berechtigungen sind kein optionales Extra, sondern Pflicht ab Tag eins.

Wer ehrlich abwägt, kommt selten zu dem Schluss, dass GraphQL für eine klassische Mittelstands-Anwendung der richtige Hebel ist. Bei einer komplexen Web-Plattform mit mehreren Frontends, mobilen Apps und mehreren Datenquellen kann der Wechsel sehr wohl Sinn ergeben. Nur eben nicht aus Mode.

Wenn du gerade vor genau dieser Entscheidung stehst und wissen willst, welche Architektur zu deinem System passt, sprechen wir das in einer Fokus-Session durch. Wir können auch direkt in der individuellen Softwareentwicklung die Architektur sauber aufsetzen, bevor sich später eine teure Korrektur ergibt.