Zwei Philosophien, ein Ziel
REST und GraphQL beantworten dieselbe Frage – wie sprechen Clients mit einem Server? – auf grundverschiedene Weise. REST modelliert die Welt als Ressourcen mit eigenen URLs, GraphQL als Datengraph, den Clients frei abfragen. Beide sind ausgereift, beide sind produktionserprobt. Die Entscheidung hängt davon ab, wer deine API konsumiert und wie unterschiedlich die Datenbedürfnisse der Clients sind.
REST: Der bewährte Standard
REST (Representational State Transfer) nutzt die Semantik, die HTTP ohnehin mitbringt: GET /users/42 liest einen Nutzer, POST /users legt einen an, DELETE /users/42 löscht ihn. Statuscodes, Header und Verben haben feste Bedeutungen – jede Middleware, jeder Proxy und jedes CDN versteht sie.
Die Stärken:
- Caching gratis:
GET-Antworten lassen sich mit Standard-HTTP-Mechanismen (ETags, Cache-Control) auf jeder Ebene cachen – vom Browser bis zum CDN - Einfachheit: Jeder Entwickler kennt REST, jedes Tool unterstützt es
- Klare Grenzen: Rate Limiting, Monitoring und Zugriffskontrolle funktionieren pro Endpoint
- Werkzeuge: Mit OpenAPI/Swagger lassen sich Schnittstellen dokumentieren und Client-Code generieren
Die Schwächen: Die festen Endpoints führen zu Overfetching (der Endpoint liefert Felder, die der Client nicht braucht) und Underfetching (der Client braucht mehrere Requests für eine Ansicht). Bei komplexen Frontends summiert sich das zu vielen Roundtrips. Teams behelfen sich mit Spezial-Endpoints oder Query-Parametern für Feldauswahl – was die API mit der Zeit unübersichtlich machen kann und genau das Problem ist, das GraphQL systematisch löst.
GraphQL: Der flexible Herausforderer
GraphQL, ursprünglich bei Facebook für die Mobile App entwickelt, dreht das Prinzip um: Es gibt einen einzigen Endpoint, und der Client beschreibt in einer Query exakt, welche Daten er braucht – inklusive verschachtelter Beziehungen:
query {
user(id: 42) {
name
posts(last: 3) {
title
commentCount
}
}
}Eine Anfrage, genau die benötigten Felder, keine Roundtrips.
Die Stärken:
- Kein Over-/Underfetching: Der Client bestimmt die Antwortstruktur
- Starkes Typsystem: Das Schema ist Vertrag und Dokumentation zugleich – Tools wie Autocomplete und Validierung entstehen daraus automatisch
- Schnelle Frontend-Iteration: Neue Ansichten brauchen keine neuen Endpoints
- Introspection: Die API ist selbstbeschreibend
Die Schwächen: Was bei REST trivial ist, wird bei GraphQL zum Projekt. Caching funktioniert nicht über HTTP-Standardmechanismen, weil alles über einen POST-Endpoint läuft – Client-Bibliotheken müssen normalisierte Caches selbst verwalten. Rate Limiting kann nicht einfach Requests zählen, sondern muss die Komplexität jeder Query bewerten (eine einzige verschachtelte Query kann so teuer sein wie hundert REST-Calls). Dazu kommen N+1-Probleme in Resolvern, die man mit Batching-Techniken wie DataLoader entschärfen muss.
Die KI-Perspektive: Warum LLM-APIs REST sind
Auffällig: Praktisch alle großen LLM-APIs – ob für Chat-Completions, Embeddings oder Bildgenerierung – sind REST-basiert. Das ist kein Zufall. Das Interaktionsmuster ist simpel: ein POST-Request mit Prompt und Parametern, eine (oft gestreamte) Antwort. Es gibt keinen verschachtelten Datengraphen, den Clients flexibel abfragen müssten – GraphQLs Kernstärke liefe ins Leere. REST plus Server-Sent Events für Token-Streaming ist die einfachste, kompatibelste Lösung. Auch für KI-Agenten und Tool-Calling sind REST-APIs mit OpenAPI-Beschreibung heute die gängige Integrationsform: Aus der Spezifikation lassen sich Tool-Definitionen für LLMs generieren.
GraphQL kann dagegen glänzen, wenn eine KI-Anwendung interne Daten aggregiert – etwa ein Dashboard, das Nutzerdaten, Modell-Metriken und Verlaufsdaten in einer Ansicht kombiniert.
Wann was?
Nimm REST, wenn:
- Du eine öffentliche API anbietest, die viele fremde Clients nutzen
- HTTP-Caching für Performance wichtig ist
- Die Datenstruktur flach und ressourcenorientiert ist (klassisches CRUD)
- Du Microservices intern verbindest und Einfachheit zählt
- Deine API von LLMs/Agenten als Tool aufgerufen werden soll
Nimm GraphQL, wenn:
- Viele verschiedene Clients (Web, iOS, Android) unterschiedliche Datenausschnitte brauchen
- Deine Daten stark verschachtelt sind und Ansichten viele Beziehungen kombinieren
- Frontend-Teams unabhängig vom Backend iterieren sollen
- Du bereit bist, in Tooling und Betrieb (Caching, Query-Komplexität, Monitoring) zu investieren
Kombination statt Entweder-oder
In der Praxis schließen sich beide nicht aus. Ein verbreitetes Muster: GraphQL als Backend-for-Frontend, das intern REST-Microservices aggregiert. Die Frontends bekommen flexible Queries, die Services bleiben einfach und cachebar. Umgekehrt bieten manche Plattformen beide Schnittstellen parallel an – REST für einfache Integrationen und Partner, GraphQL für die eigenen, datenhungrigen Apps. Entscheidend ist nicht Ideologie, sondern die Frage: Wer konsumiert die API, und wie unterschiedlich sind die Bedürfnisse? Im Zweifel gilt: Starte mit REST – und führe GraphQL gezielt dort ein, wo der Bedarf an flexiblen Queries nachweislich besteht.