GraphQL vs. REST: Welcher API-Stil, und wann?

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

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:

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:

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 / 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 — 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

// 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) }
}

// 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

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, 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 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

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 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 – ü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.