REST vs GraphQL: praktischer Vergleich fuer die API-Wahl

Zwei Ansaetze fuer dasselbe Problem

REST und GraphQL loesen beide dasselbe grundlegende Problem: Wie fordert ein Client (Browser, mobile App, anderer Dienst) Daten von einem Server an? Aber sie loesen es auf sehr unterschiedliche Weise, und die Wahl hat reale Auswirkungen auf Leistung, Entwicklererfahrung und langfristige Wartbarkeit.

REST ist seit Mitte der 2000er das dominierende API-Paradigma. GraphQL wurde 2012 von Facebook entwickelt und 2015 als Open Source veroeffentlicht. Beide werden heute breit in der Produktion eingesetzt. Die Frage ist nicht, welches abstrakt "besser" ist, sondern welches zu Ihrer konkreten Situation passt.

Wie REST funktioniert

REST (Representational State Transfer) organisiert Ihre API um Ressourcen. Jede Ressource (ein Benutzer, ein Produkt, eine Bestellung) hat eine URL, und Sie interagieren mit ihr ueber Standard-HTTP-Methoden.

Grundkonzepte

• Ressourcen: Alles ist eine Ressource mit einer eindeutigen URL. /users/42 ist der Benutzer mit ID 42.
• HTTP-Methoden: GET liest, POST erstellt, PUT/PATCH aktualisiert, DELETE loescht.
• Zustandslos: Jede Anfrage enthaelt alle Informationen, die der Server benoetigt.
• Standard-HTTP-Statuscodes: 200 Erfolg, 404 nicht gefunden, 401 nicht autorisiert.

Beispiel: Benutzerprofil abrufen

GET /api/users/42 gibt die vollstaendige Benutzer-Ressource zurueck: Name, E-Mail, Telefon, Adresse, Einstellungen, Avatar. Der Client bekommt alles, ob er es braucht oder nicht.

Fuer die Bestellungen desselben Benutzers braucht es eine zweite Anfrage: GET /api/users/42/orders. Zwei Anfragen fuer eine Seite.

Wie GraphQL funktioniert

GraphQL verfolgt einen grundlegend anderen Ansatz. Statt mehrerer Endpunkte gibt es einen einzigen. Der Client spezifiziert genau, welche Daten er braucht, und der Server liefert praezise diese Daten.

Grundkonzepte

• Einzelner Endpunkt: Alle Anfragen gehen an eine URL (typischerweise /graphql).
• Client-gesteuerte Abfragen: Der Client definiert Form und Inhalt der Antwort.
• Typisiertes Schema: Die API hat ein Schema, das alle verfuegbaren Typen, Felder und Beziehungen definiert.
• Verschachtelte Daten: Verwandte Daten koennen in einer einzigen Abfrage abgerufen werden.

Beispiel: Dieselben Daten in einer Anfrage

POST /graphql mit { user(id: 42) { name email department orders(last: 5) { id date total status } } }

Eine Anfrage. Die Antwort enthaelt genau die angeforderten Felder. Kein Telefon, keine Adresse, keine Einstellungen.

Das Over-Fetching- und Under-Fetching-Problem

Over-Fetching

Der Server liefert mehr Daten als noetig. Auf mobilen Verbindungen verschwendet das Bandbreite und verlangsamt die Erfahrung.

Under-Fetching

Der Server liefert nicht genug Daten, was den Client zu mehreren sequenziellen Anfragen zwingt. Das fuehrt zu Wasserfall-Anfragen mit zusaetzlicher Latenz.

GraphQL loest beide Probleme. Der Client fragt genau das Noetige ab und bekommt alles in einer Anfrage.

Wann REST verwenden

Einfache CRUD-Operationen

Bei einfachen Datenstrukturen passt RESTsressourcenorientiertes Modell natuerlich zum Domain.

Oeffentliche APIs

Leichtere Lernkurve, ausgereifte Dokumentationstools (Swagger/OpenAPI).

Caching

REST-URLs funktionieren natuerlich mit HTTP-Caching auf allen Ebenen. Fuer oeffentliche Websites, bei denen Caching entscheidend ist, uebertreffen REST oder statische Seiten GraphQL. Siehe unseren Artikel ueber Website-Geschwindigkeit und Geschaeftsauswirkung.

Datei-Uploads

REST handhabt binaere Daten natuerlich. GraphQL braucht Umgehungsloesungen.

Wann GraphQL verwenden

Komplexe Datenbeziehungen

Bei tiefen Beziehungen im Datenmodell erlauben GraphQLs verschachtelte Abfragen effizientes Traversieren.

Mehrere Frontend-Clients

Web-App, mobile App, Partner-Integration: Jeder Client fordert genau die benoetigten Daten an.

Schnelle Frontend-Iteration

Frontend-Entwickler aendern ihre Datenanforderungen ohne Backend-Aenderungen.

Mobile Anwendungen

Reduzierte Latenz und Datenverbrauch auf mobilen Verbindungen.

Leistungsueberlegungen

Netzwerkleistung

GraphQL gewinnt typischerweise dank reduzierter Roundtrips und kleinerer Payloads.

Serverleistung

GraphQL-Abfragen koennen serverseitig rechenintensiv sein. Ohne Schutzmassnahmen koennen tief verschachtelte Abfragen den Server ueberlasten.

Caching

REST hat einen klaren Vorteil beim HTTP-Level-Caching.

Sicherheitsimplikationen

Rate Limiting

REST ist einfach zu begrenzen. GraphQL erfordert Beruecksichtigung der Abfragekomplexitaet.

Abfragetiefe-Angriffe

GraphQL fuehrt ein spezifisches Risiko ein: boesartige, tief verschachtelte Abfragen. Jede GraphQL-API braucht maximale Abfragetiefe, Komplexitaets-Scoring und Timeouts.

Autorisierung

REST: pro Endpunkt. GraphQL: pro Feld oder pro Typ. Granularer, aber komplexer zu implementieren.

Introspektion

In Produktion fuer oeffentliche APIs deaktivieren.

Tooling-Vergleich

Kategorie	REST	GraphQL
API-Dokumentation	Swagger/OpenAPI (ausgereift)	GraphiQL, Playground (selbstdokumentierend)
API-Tests	Postman, Insomnia, curl	Postman, Insomnia, Apollo Studio
Client-Bibliotheken	Axios, Fetch API	Apollo Client, urql, Relay
Server-Frameworks	Express, FastAPI, Spring Boot	Apollo Server, Mercurius, Hasura
Code-Generierung	OpenAPI Generator	GraphQL Code Generator

Entscheidungsrahmen

1. Wie komplex ist Ihr Datenmodell? Einfach: REST. Komplex mit tiefen Beziehungen: GraphQL.
2. Wie viele Client-Typen bedienen Sie? Ein oder zwei mit aehnlichen Beduerfnissen: REST. Mehrere mit unterschiedlichen: GraphQL.
3. Wie wichtig ist Caching? HTTP-Caching Prioritaet: REST. Applikations-Caching akzeptabel: beide.
4. Erfahrung des Teams? Beruecksichtigen Sie die GraphQL-Lernkurve.
5. Oeffentliche oder interne API? Oeffentlich: meist REST. Intern: nach obigen Faktoren.

Der hybride Ansatz

Sie muessen sich nicht exklusiv entscheiden. Viele Produktionssysteme nutzen beides:

• REST fuer einfaches CRUD und oeffentliche APIs, wo Caching und Einfachheit zaehlen.
• GraphQL als BFF (Backend for Frontend), das Daten aus REST-Microservices aggregiert.
• REST fuer Datei-Uploads und Webhooks, GraphQL fuer Datenabfragen.

Wenn Sie eine API-Architektur fuer ein neues Projekt planen, kann unser Entwicklungsteam in Lugano Ihre Anforderungen bewerten und den richtigen Ansatz empfehlen.

Zusammenfassung: Wann was verwenden

Szenario	Empfehlung
Einfache CRUD-Anwendung	REST
Oeffentliche API fuer Drittentwickler	REST
Inhaltsreiche Website mit CDN	REST oder statische Generierung
Komplexe Daten mit tiefen Beziehungen	GraphQL
Mehrere Frontend-Clients (Web + Mobil)	GraphQL
Schnelle Frontend-Iteration	GraphQL
Echtzeit-Subscriptions	GraphQL
Microservice-Aggregationsschicht	GraphQL als BFF
Datei-Uploads	REST
Webhooks	REST