---
term: 'GraphQL vs. REST'
seoTitle: 'GraphQL vs. REST: Unterschiede, Trade-offs und wann was passt'
headline: 'GraphQL vs. REST: Welcher API-Stil, und wann?'
slug: graphql-vs-rest
category: api-realtime
shortDefinition: 'REST ist ein API-Stil mit vielen festen Endpoints; GraphQL ist eine Abfragesprache, bei der Clients einen Endpoint nur nach den benötigten Feldern fragen.'
relatedTerms:
  - overfetching-underfetching
  - auto-generated-database-apis
  - n-plus-one-query-problem
  - api-payload-optimization
contrastsWith:
  - overfetching-underfetching
aboutTerms:
  - 'GraphQL'
  - 'REST API'
faq:
  - question: 'Was ist der Hauptunterschied zwischen GraphQL und REST?'
    answer: 'Die Form des Vertrags. REST stellt viele Ressourcen-Endpoints bereit, von denen jeder eine vom Server definierte Antwort liefert – Sie nehmen, was der Endpoint hergibt. GraphQL stellt einen einzigen Endpoint mit typisiertem Schema bereit, und jeder Client schreibt eine Query, die genau die Felder und verschachtelten Relationen benennt, die er braucht. REST legt Antworten auf dem Server fest; GraphQL verlagert diese Entscheidung zum Client.'
  - question: 'Ist GraphQL schneller als REST?'
    answer: 'Für Screens, die Daten aus mehreren Ressourcen brauchen, meistens – eine Query ersetzt mehrere Roundtrips, und der Payload enthält nur die angeforderten Felder. Für eine einzelne, einfache Ressource ist REST oft schneller, weil sich seine über URLs adressierten Antworten hervorragend in CDNs cachen lassen. Und schlecht geschriebene Resolver können GraphQL über das N+1-Problem langsamer machen als alles andere. Die Last entscheidet.'
  - question: 'Was sind Overfetching und Underfetching?'
    answer: 'Die beiden REST-Schmerzen, für deren Lösung GraphQL gebaut wurde. Overfetching: Ein Endpoint liefert die ganze Ressource, obwohl der Screen drei Felder braucht. Underfetching: Ein Aufruf reicht nicht, also stellt der Client N Folgeanfragen für zugehörige Daten. Feldauswahl und verschachtelte Queries lösen beides – deshalb zieht es datenintensive Apps mit mehreren Clients zuerst zu GraphQL.'
  - question: 'Löst GraphQL REST ab?'
    answer: 'Nein – die Branchendaten sprechen für Koexistenz. Umfragen zeigen durchweg, dass die überwältigende Mehrheit der Teams REST nutzt und etwa ein Drittel GraphQL, meist zusätzlich zu REST statt anstelle davon. Das vorherrschende Muster in Unternehmen ist hybrid: REST (oder RPC) zwischen Diensten und für öffentliche APIs, GraphQL als Aggregationsschicht für Frontend-Clients.'
  - question: 'Wie unterscheidet sich das Caching zwischen REST und GraphQL?'
    answer: 'REST-Antworten liegen unter eindeutigen URLs, daher cachen Browser und CDNs sie ohne jeden Aufwand – die stille Superkraft von REST. GraphQL sendet in der Regel POSTs an einen einzigen Endpoint, was URL-basiertes Caching aushebelt; das Ökosystem gleicht das mit normalisierten Client-Caches und Persisted Queries über GET aus. Caching ist das stärkste Einzelargument für REST bei öffentlichen, leselastigen APIs.'
  - question: 'Wie unterscheidet sich die Versionierung?'
    answer: 'REST versioniert explizit – ein v2 in URL oder Header – und betreibt während einer Migration beide Versionen. GraphQL strebt versionslose Evolution an: neue Felder frei hinzufügen, alte als deprecated markieren, die Nutzungstelemetrie beobachten und sie entfernen, sobald kein Client mehr danach fragt. Beides funktioniert; GraphQL tauscht Versionszeremonie gegen Disziplin bei der Schema-Governance.'
  - question: 'Wie unterscheiden sich Fehler bei beiden?'
    answer: 'REST stützt sich auf HTTP-Statuscodes – ein 404 ist für jeden Proxy, jedes Monitoring und jede Client-Bibliothek sichtbar. GraphQL liefert meist 200 mit einem errors-Array neben Teildaten; das ermöglicht Teilerfolge, bedeutet aber, dass das Monitoring Antwort-Bodys parsen muss, statt sich auf Statuscodes zu verlassen. Ein echter betrieblicher Unterschied, keine Fußnote.'
  - question: 'Wann sollten Sie weiterhin REST wählen?'
    answer: 'Konkrete Auslöser: öffentliche APIs mit vielen Drittkonsumenten, stark cachebarer Lesetraffic, einfaches ressourcenförmiges CRUD, Datei-Uploads und -Downloads, Integrationen im Webhook-Stil und Teams ohne Betriebserfahrung mit GraphQL. REST ist der Standard, den alles unterstützt; GraphQL ist der Spezialist, den Sie für datendichte Frontends mit mehreren Clients holen.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'GraphQL official documentation'
    url: 'https://graphql.org/learn/'
  - name: 'GraphQL security best practices (graphql.org)'
    url: 'https://graphql.org/learn/security/'
  - name: 'Architectural Styles and the Design of Network-based Software Architectures — Roy Fielding'
    url: 'https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm'
  - name: 'GraphQL API documentation'
    url: 'https://docs.parseplatform.org/graphql/guide/'
  - name: 'GraphQL — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/GraphQL'
  - name: 'REST — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/REST'
cta:
  title: 'Beide APIs, null Zeilen API-Code'
  text: 'Back4app generiert REST und GraphQL automatisch aus demselben Schema: über URLs cachebares REST für die einfachen Pfade, typisiertes GraphQL mit verschachtelten Queries für die datendichten Screens. Wählen Sie pro Client – bauen müssen Sie keine von beiden.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-22'
translationKey: graphql-vs-rest
---

**REST ist ein API-Stil mit vielen festen Endpoints; GraphQL ist eine Abfragesprache, bei der Clients einen Endpoint nur nach den benötigten Feldern fragen.** Im Kern geht es beim Vergleich darum, *wer die Form der Antwort bestimmt*: Bei REST hat der Server sie zur Entwurfszeit festgelegt; bei GraphQL entscheidet der Client pro Anfrage. Alles andere – Caching, Versionierung, Fehler, Performance – ergibt sich aus dieser einen Umkehrung.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| REST | Viele Endpoints, vom Server definierte Antworten, HTTP-natives Caching |
| GraphQL | Ein Endpoint, typisiertes Schema, vom Client gewählte Felder und Verschachtelung |
| Wo GraphQL gewinnt | Overfetching und Underfetching verschwinden; ein Roundtrip pro Screen |
| Wo REST gewinnt | CDN-Caching, Einfachheit, universelle Unterstützung |
| Die Realität 2026 | Koexistenz – REST überall, GraphQL als Aggregationsschicht für Frontends |

## Derselbe Screen, auf beide Arten

Ein Profil-Screen braucht einen Benutzer, seine fünf neuesten Posts und die Zahl der Follower. REST spricht in Ressourcen:

```text
GET /users/42               → 38 Felder, gebraucht: 3     (Overfetching)
GET /users/42/posts?limit=5 → zweiter Roundtrip           (Underfetching)
GET /users/42/followers     → dritter Roundtrip
```

GraphQL spricht in einer einzigen, geformten Frage:

```text
POST /graphql
query {
  user(id: 42) {
    name
    avatarUrl
    posts(first: 5) { title likes }
    followers { totalCount }
  }
}
→ ein Roundtrip, genau diese Felder, sonst nichts
```

Der Abstand ist kleiner, als die Schlagzeilen vermuten lassen: Gut entworfenes REST unterstützt ebenfalls Feldauswahl – und die Query-Builder der SDKs machen sie zur selbstverständlichen Gewohnheit:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
const query = new Parse.Query('Article');
query.equalTo('status', 'published');
query.select('title', 'views');        // field selection, GraphQL-style
const articles = await query.find();   // lean payload over the REST API
// The same backend also speaks real GraphQL: query { articles { ... } }
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
final query = QueryBuilder<ParseObject>(ParseObject('Article'))
  ..whereEqualTo('status', 'published')
  ..keysToReturn(['title', 'views']);   // field selection, GraphQL-style
final response = await query.query();   // lean payload over the REST API
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
let query = Article.query("status" == "published")
  .select("title", "views")             // field selection, GraphQL-style
query.find { result in
  if case .success(let articles) = result { render(articles) }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
val query = ParseQuery.getQuery<ParseObject>("Article")
query.whereEqualTo("status", "published")
query.selectKeys(listOf("title", "views"))  // field selection, GraphQL-style
query.findInBackground { articles, e -> if (e == null) render(articles) }
```

## GraphQL vs. REST im Überblick

| Dimension | REST | GraphQL |
| --- | --- | --- |
| Endpoints | Viele, an Ressourcen ausgerichtet | Einer, am Schema ausgerichtet |
| Form der Antwort | Vom Server definiert | Vom Client pro Query gewählt |
| Typisierung | Konvention (OpenAPI optional) | Vom Schema erzwungen, per Introspection lesbar |
| Roundtrips | Einer pro Ressource | Einer pro Screen |
| Caching | HTTP-/CDN-nativ, über URLs | Normalisiert im Client; Persisted Queries |
| Versionierung | /v1 → /v2 | Weiterentwickeln + deprecaten, versionslos |
| Fehler | HTTP-Statuscodes | 200 + errors-Array, Teilergebnisse |
| Echtzeit | Separat (Webhooks, Sockets) | Subscriptions in der Spezifikation |
| Lernkurve | Minimal | Schema, Resolver, Kostenkontrolle |
| Passt zuerst für | Öffentliches, cachebares, einfaches CRUD | Datendichte Frontends mit mehreren Clients |

```mermaid
flowchart LR
  accTitle: Anfragefluss bei REST mit mehreren Endpoints gegenüber GraphQL mit einem Endpoint
  accDescr: Ein REST-Client stellt drei Anfragen an separate Ressourcen-Endpoints und setzt das Ergebnis zusammen; ein GraphQL-Client sendet eine Query an einen einzigen Endpoint, der alle Felder auflöst und eine einzige geformte Antwort zurückgibt.
  subgraph R["REST"]
    C1["Client"] --> E1["/users/42"]
    C1 --> E2["/users/42/posts"]
    C1 --> E3["/users/42/followers"]
  end
  subgraph G["GraphQL"]
    C2["Client"] -->|"eine geformte Query"| S["/graphql<br/>Schema + Resolver"]
  end
```

## Was die Vergleichsseiten auslassen

**Das N+1-Problem ist umgezogen, nicht verschwunden.** Eine GraphQL-Query nach Posts mit Autoren löst naiv einen Resolver-Aufruf pro Post aus – dieselbe [N+1-Pathologie](/glossary/de/n-plus-1-problem/), mit der ORMs berüchtigt wurden, nur jetzt auf dem Server. Das übliche Gegenmittel ist Batching: Ein Loader pro Anfrage sammelt die Autoren-IDs und holt sie in einer einzigen Abfrage. Wer GraphQL ohne Batching-Strategie einführt, holt sich den schlimmsten Performance-Bug von REST an neuer Adresse ins Haus.

**Fehler sind eine Betriebsentscheidung.** "200 mit einem errors-Array" bedeutet, dass Dashboards, Alerting und CDN-Logik, die auf Statuscodes aufbauen, standardmäßig blind sind. Teams, die mit GraphQL gut fahren, behandeln die Beobachtbarkeit von Fehlern als Teil der Einführung, nicht als Nachgedanken.

**Unbegrenzte Queries brauchen Grenzen.** Ein flexibler Endpoint bedeutet, dass eine einzige Query den gesamten Graphen durchlaufen kann – [die offiziellen Sicherheitsempfehlungen](https://graphql.org/learn/security/) lauten Tiefenlimits, Budgets für Query-Kosten und Allowlists aus Persisted Queries für eigene Clients. Bei REST ergab sich die Kostenkontrolle implizit aus den festen Endpoints; bei GraphQL ist sie Ihre Aufgabe.

## Typische Anwendungsfälle

- **GraphQL:** mobile Apps in langsamen Netzen, Dashboards, die viele Entitäten zusammenführen, Produkte mit Web-, Mobile- und Partner-Clients mit auseinanderlaufendem Datenbedarf, schnelle Frontend-Iteration gegen ein stabiles Schema.
- **REST:** öffentliche Entwickler-APIs, cachebare Auslieferung von Inhalten, Webhook- und Integrationsschnittstellen, Dateiübertragung, Aufrufe zwischen Diensten, bei denen Einfachheit gewinnt.
- **Beides (der Normalfall in Unternehmen):** REST oder RPC zwischen Backend-Diensten; eine GraphQL-Schicht, die sie für Frontends zusammenführt – das Backend-for-Frontend-Muster mit Schema.

## Sollten Sie GraphQL oder REST wählen? Eine Entscheidungsmatrix

| Wählen Sie REST, wenn… | Wählen Sie GraphQL, wenn… | Nutzen Sie beides, wenn… |
| --- | --- | --- |
| Dritte die API konsumieren | Screens viele Ressourcen zusammenführen | Dienste REST sprechen, Frontends geformte Daten wollen |
| CDN-Caching die Last trägt | Clients unterschiedliche Daten brauchen | Eine öffentliche API und ein Produkt-Frontend koexistieren |
| Ressourcen 1:1 auf Screens passen | Overfetching mobile Nutzer ausbremst | Sie schrittweise migrieren |
| Das Team diese Woche liefern muss | Typisierte Verträge die Frontend-Arbeit beschleunigen | Verschiedene Teams verschiedene Schichten verantworten |
| Dateien und Webhooks dominieren | Echtzeit-Subscriptions zentral sind | Sie diese Debatte nicht noch einmal führen wollen |

Der ehrliche Standard: Beginnen Sie mit REST und ergänzen Sie GraphQL, wenn der Schmerz, Daten für mehrere Clients zu formen, tatsächlich eintritt – und wenn Ihre Plattform beides aus einem Schema generiert, ist die Wahl keine Architekturfrage mehr, sondern eine pro Anfrage.

## Grenzen und Trade-offs

- **REST:** Over-/Underfetching auf datendichten Screens, Versionsmigrationen, auseinanderdriftende Antwortformen zwischen Teams und Dokumentation für N Endpoints.
- **GraphQL:** Caching verlangt Maschinerie, Kostenkontrolle verlangt Wachsamkeit, Resolver verlangen Disziplin beim Batching, und das Muster "200 mit Fehlern" verlangt Umbauten an der Observability.
- **Beide:** Keiner der beiden Stile repariert ein schlechtes Datenmodell – eine verworrene Domäne ergibt in jedem Stil eine verworrene API, wie schon [die REST-Dissertation selbst](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) stillschweigend nahelegt: Die Constraints betrafen immer die Architektur darunter.

## GraphQL und REST mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Damit löst sich das Dilemma dieses Artikels an der Wurzel auf: Beide API-Stile werden [aus demselben Schema generiert](https://docs.parseplatform.org/graphql/guide/) – über URLs cachebare REST-Endpoints und eine typisierte GraphQL-API mit verschachtelten Queries –, dazu SDKs, deren Feldauswahl (die Code-Tabs oben) den zentralen Vorteil von GraphQL über beide Transportwege liefert. Wählen Sie pro Client, wechseln Sie pro Screen, und schreiben Sie die API-Schicht nie selbst.