GraphQL vs. REST - Welcher API Ansatz passt zu deinem Projekt?

APIs sind die unsichtbare Brücke zwischen Datenbanken, Backend-Systemen und den Anwendungen, die wir täglich nutzen – egal ob Website, Mobile App oder Cloud-Service. Lange Zeit war REST der unangefochtene Standard für Web-APIs. In den letzten Jahren ist jedoch GraphQL als moderne Alternative hinzugekommen, die mehr Flexibilität und Effizienz verspricht.

In diesem Artikel werfen wir einen Blick auf beide Ansätze, vergleichen ihre Stärken und Schwächen und zeigen anhand praxisnaher Beispiele, wann sich welcher Ansatz lohnt.

REST – der bewährte Klassiker

⁠Was ist REST?

REST (Representational State Transfer) ist ein Architektur-Stil für Webanwendungen, bei dem jede Art von Ressource, wie beispielsweise „Autoren“ oder „Bücher“, über eine eindeutige Internetadresse (URL) angesprochen werden kann. Jede Ressource hat ihren eigenen Endpunkt, und über HTTP-Methoden wie GET, POST, PUT oder DELETE können Daten abgefragt, hinzugefügt, geändert oder gelöscht werden.

Beispiel (REST)

Alle Autoren abrufen:
GET /api/authors
Antwort:

[
⁠ { "id": 1, "name": "Autor A", "age": 34 },
⁠ { "id": 2, "name": "Autor B", "age": 28 }
⁠]

Ein einzelner Autor abrufen:
GET /api/authors/1
Antwort:

{ "id": 1, "name": "Autor A", "age": 34 }

Bücher des Autors abrufen:
GET /api/authors/1/books

[
⁠  { "id": 1, "title": "Java für Anfänger", "pages": 320 },
⁠  { "id": 2, "title": "GraphQL verstehen", "pages": 280 }
⁠]

Vorteile von REST:

Einfach zu verstehen und umzusetzen.
Weit verbreitet, von allen gängigen Tools unterstützt.
Nutzt HTTP-Caching sehr effizient.

Nachteile von REST:

Overfetching: Der Client bekommt oft mehr Daten als nötig.
Underfetching: Mehrere Requests nötig, um komplexe Daten zu erhalten.
Neue Anwendungsfälle erfordern oft neue Endpunkte.

GraphQL – die flexible Alternative

Was ist GraphQL?

GraphQL wurde 2015 von Facebook entwickelt und verfolgt einen völlig anderen Ansatz. Statt vieler Endpunkte gibt es nur einen einzigen Endpoint (/graphql). Dort beschreibt der Client genau, welche Daten er benötigt.

Beispiel (GraphQL)
Query, um einen Autor und seine Bücher abzurufen:

query {
⁠  author(id: 1) {
⁠    name
⁠    age
⁠    books {
⁠      title
⁠      pages
⁠    }
⁠  }
⁠}

Antwort:

{
⁠  "data": {
⁠     "author": {
⁠       "name": "Autor A",
⁠       "age": 34,
⁠       "books": [
⁠            { "title": "Java für Anfänger", "pages": 320 },
⁠            { "title": "GraphQL verstehen", "pages": 280 }
⁠        ]
⁠     }
⁠   }
⁠}

Vorteile von GraphQL:

Exakt die benötigten Daten abrufen.
Verschachtelte Daten (Autor + Bücher) in einem Request.
Stark typisiertes Schema für bessere Dokumentation.
Interaktive Tools wie GraphiQL erleichtern Entwicklung und Test.

Nachteile von GraphQL:

Caching schwieriger als bei REST.
Einarbeitung nötig, besonders bei komplexen Abfragen.
Für kleine Projekte evtl. Overhead.

Praxisbeispiele: Autoren & Bücher

REST

• ⁠Alle Autoren abrufen: GET /api/authors
• Für jeden Autor die Bücher abrufen: ⁠GET /api/authors/{id}/books

  Ergebnis: ⁠mehrere Requests nötig, verschachtelte Daten erfordern zusätzliche Endpunkte.

GraphQL
Query für alle Autoren und deren Bücher:

query {
⁠    authors {
⁠       id
⁠       name
⁠       books {
⁠          id
⁠          title
⁠          pages
⁠       }
⁠    }
⁠}

Ergebnis: Ein Request liefert alle relevanten Daten, verschachtelt und übersichtlich.

⁠
⁠Komplexere Praxisbeispiele

Angenommen, jedes Buch hat Kapitel und jedes Kapitel hat Rezensionen.

• ⁠REST: mehrere verschachtelte Endpunkte nötig (/authors/1/books/2/chapters/5/reviews).
• GraphQL: ein einziger Request:
  

query {
⁠    author(id: 1) {
⁠       name
⁠       books {
⁠           title
⁠           chapters {
⁠              title
⁠              reviews {
⁠                rating
⁠                comment
⁠              }
⁠           }
⁠        }
⁠     }
⁠}

Ergebnis: Alle verschachtelten Daten auf einmal, ohne zusätzliche Requests.

Fehlerbehandlung & Debugging

• REST: Fehler über HTTP-Statuscodes (404 = nicht gefunden, 500 = Serverfehler).
• GraphQL: Fehler erscheinen im errors-Feld, z. B.:
  

{
⁠   "data": null,
⁠   "errors": [
⁠       { "message": "Autor nicht gefunden", "locations": [{ "line": 2, "column": 3 }] }
⁠   ]
⁠}

GraphQL ermöglicht präzisere Fehlermeldungen für einzelne Felder, was die Fehlerdiagnose erleichtert.

Versionierung & Weiterentwicklung

• REST: Neue Versionen bei Änderungen (/v2/authors).
• GraphQL: Schema kann erweitert werden, alte Queries bleiben gültig.
Beispiel: Neues Feld biography kann hinzugefügt werden, ohne dass bestehende Clients ihre Queries ändern müssen.

Performance, Tools & Sicherheit

Performance

REST liefert oft mehr Daten als nötig (gut für Caching), GraphQL liefert genau die angefragten Daten (weniger Overhead, aber Caching komplexer).

Tools

• REST: Postman, Swagger – Testen und Dokumentieren von Endpunkten.
• GraphQL: GraphiQL, Apollo Studio – interaktive Abfragen, sofortiges Feedback.

Sicherheit

• REST: viele Endpunkte, jeder benötigt eigene Authentifizierung.
• GraphQL: ein Endpunkt, daher Rollenkontrolle, Rate-Limiting und Query Depth-Limiting zum Schutz vor Überlastung nötig.

Client-Perspektive

Mobile Apps benötigen oft weniger Daten als Web-Apps. REST erfordert dafür eigene Endpunkte, GraphQL kann exakt die benötigten Felder liefern. Frontend-Teams können neue Features schneller implementieren, ohne auf Backend-Änderungen zu warten.

Einsatzszenarien & Praxisfälle

• REST: Ideal für einfache CRUD-Operationen und stabile Endpunkte.
• GraphQL: Stärken bei komplexen Datenstrukturen, Social Media Plattformen, E-

Commerce oder wenn viele unterschiedliche Clients existieren.

Viele Unternehmen nutzen eine Kombination: REST für einfache Endpunkte, GraphQL für flexible Abfragen.

Tipps für Einsteiger

• Interaktive Tools: GraphiQL oder Apollo Studio ausprobieren.
• ⁠Schrittweise Schema-Erweiterung für praxisnahes Lernen.
  

Fazit

REST überzeugt durch Stabilität, Einfachheit und breite Unterstützung, während GraphQL mit Flexibilität und Effizienz bei komplexen Datenstrukturen punktet – besonders in modernen, frontend-orientierten Anwendungen. Beide Ansätze schließen sich nicht aus, sondern lassen sich je nach Projektbedarf sinnvoll kombinieren.