Programmierung · Web · API

REST vs. GraphQL

Du baust eine API und die erste große Weggabelung ist der Stil: REST oder GraphQL. Sie lösen dasselbe Problem — Clients über HTTP Daten lesen und schreiben zu lassen — legen die Kontrolle aber in unterschiedliche Hände. Dieser Leitfaden vergleicht sie ehrlich anhand von Datenabruf, Caching, Komplexität und Tooling, damit du fundiert wählen kannst.

Der grundlegende Unterschied

• REST — viele Endpunkte (URLs), von denen jeder eine feste Form von Daten zurückgibt. Du rufst /users/42 auf und erhältst, was dieser Endpunkt liefern soll. Der Server entscheidet die Form.
• GraphQL — ein einziger Endpunkt, an den der Client eine Abfrage sendet, die genau die gewünschten Felder nennt, und nur diese empfängt. Der Client entscheidet die Form.

Beide laufen über HTTP und sprechen in der Regel JSON. Der Unterschied: wer kontrolliert, was zurückkommt.

Dieselbe Anfrage, auf beide Arten

Den Namen eines Nutzers und die Titel seiner Beiträge abrufen. In REST sind das oft zwei Aufrufe; in GraphQL eine präzise Abfrage:

-- REST (oft zwei Rundläufe)
GET /users/42
GET /users/42/posts

-- GraphQL (eine Abfrage, exakte Felder)
POST /graphql
{ user(id: 42) { name posts { title } } }

Over-Fetching und Under-Fetching

Das ist das Hauptargument von GraphQL. Mit den festen Antworten von REST stößt du oft auf:

• Over-Fetching — der Endpunkt gibt weit mehr zurück als nötig (Dutzende Felder, um einen Namen anzuzeigen).
• Under-Fetching — ein Endpunkt reicht nicht, du machst mehrere weitere Aufrufe, um einen Screen aufzubauen.

GraphQL vermeidet beides: der Client fragt genau die gewünschten Felder an, in einer Abfrage. Für Apps mit vielen Screens (vor allem mobil) ist diese Präzision der Hauptgrund für die Einführung.

Wo REST noch gewinnt

• Caching — eigene URLs + GET lassen REST natürlich mit HTTP-Caches und CDNs funktionieren. GraphQL (POST an einen Endpunkt) braucht einen Client-Cache oder persistierte Abfragen.
• Einfachheit — für ressourcenorientierte Daten gibt es bei REST weniger zu lernen und zu betreiben; kein Schema, keine Resolver, keine Abfragekostengrenzen.
• Tooling & Allgegenwart — REST ist überall, mit ausgereiftem, kostenlosem Tooling und sanfter Lernkurve.

Wo GraphQL gewinnt

• Flexible, präzise Daten — Clients holen sich genau das, was sie brauchen, nicht mehr.
• Weniger Rundläufe — verknüpfte Daten in einer einzigen Abfrage statt mehrerer Aufrufe.
• Ein typisiertes Schema — ein selbstdokumentierender Vertrag und mächtiges Tooling (Introspektion, Codegen).

Der Preis: mehr Serverkomplexität (Schema, Resolver, Schutz vor teuren Abfragen) und ein Cache, den man entwerfen muss, statt ihn gratis zu bekommen.

Wie man wählt

• Nimm REST für einfachere, ressourcenorientierte APIs, bei denen kostenloses HTTP-Caching, Allgegenwart und eine sanfte Kurve zählen.
• Nimm GraphQL, wenn Clients vielfältige, sich entwickelnde Datenbedürfnisse haben und du Over-/Under-Fetching vermeiden willst — und die zusätzliche Serverkomplexität verkraften kannst.
• Beides ist in Ordnung — viele Systeme stellen REST für einfachen/öffentlichen Zugriff und GraphQL für reichhaltige Client-Apps bereit.

Häufige Fragen

Was ist der Unterschied zwischen REST und GraphQL?

REST und GraphQL sind zwei Stile, um eine Web-API zu bauen. Eine REST-API stellt viele URLs (Endpunkte) bereit, von denen jeder eine feste Datenform zurückgibt — du rufst /users/42 auf und erhältst, was dieser Endpunkt liefert. GraphQL stellt einen einzigen Endpunkt bereit, an den der Client eine Abfrage sendet, die genau die gewünschten Felder beschreibt, und nur diese empfängt. Kurz gesagt: Bei REST entscheidet der Server die Antwortform pro Endpunkt; bei GraphQL entscheidet sie der Client pro Abfrage. Beide laufen über HTTP und tauschen in der Regel JSON aus.

Ist GraphQL besser als REST?

Keiner ist universell besser — sie machen unterschiedliche Kompromisse. GraphQL glänzt, wenn Clients flexible, präzise Daten brauchen (z. B. unterschiedliche Mobile-Screens), denn es vermeidet Over- und Under-Fetching und bündelt mehrere Aufrufe in einer Abfrage. REST glänzt bei einfachen, ressourcenorientierten APIs und profitiert von kostenlosem, ausgereiftem HTTP-Caching und solidem Tooling. GraphQL fügt Serverkomplexität hinzu (Schema, Resolver, Kontrolle der Abfragekosten); REST kann mehrere Rundläufe erfordern. Wähle nach den Datenbedürfnissen deiner Clients, nicht nach Mode.

Was ist Over-Fetching und Under-Fetching?

Over-Fetching ist, wenn ein Endpunkt mehr Daten zurückgibt als nötig — du fragst einen Nutzer an und erhältst Dutzende Felder, um nur einen Namen anzuzeigen, und verschwendest Bandbreite. Under-Fetching ist, wenn ein Endpunkt nicht genug zurückgibt und dich zu mehreren Aufrufen zwingt, um zusammenzusetzen, was ein Screen verlangt. REST ist dafür anfällig, weil jeder Endpunkt eine feste Antwort hat. GraphQL vermeidet beides, indem der Client genau die gewünschten Felder in einer Abfrage anfragt — das ist sein Hauptreiz.

REST oder GraphQL: was lässt sich besser cachen?

REST ist in der Regel einfacher zu cachen. Da REST eigene URLs und HTTP-Methoden nutzt (vor allem GET für Lesezugriffe), funktioniert es natürlich mit HTTP-Caches, CDNs und Browser-Cache, die nach URL indiziert sind. GraphQL sendet Abfragen meist per POST an einen einzigen Endpunkt, sodass standardmäßiges HTTP-Caching nicht von Haus aus greift und du dich auf einen clientseitigen Cache (wie Apollo) oder persistierte Abfragen verlässt. Wenn dir kostenloses, standardmäßiges HTTP-Caching wichtig ist, spricht das für REST.

Fazit

REST und GraphQL sind keine Feinde — sie sind zwei Antworten auf „wer entscheidet die Antwortform?“. REST behält sie auf der Serverseite mit einfachen, cachebaren Endpunkten; GraphQL überlässt sie dem Client für präzise, flexible Abfragen, zum Preis erhöhter Komplexität. Wähle nach den Datenbedürfnissen deiner Clients und deinem Appetit auf operative Komplexität — und denk daran, dass du beide dort einsetzen kannst, wo jeweils das eine passt.