--- title: "REST vs GraphQL 2026: Welche API-Architektur passt zu deinem Projekt?" description: "REST vs GraphQL im direkten Vergleich. Performance, Flexibilität, Lernkurve und wann du welche API-Architektur wählen solltest. Mit Praxis-Beispielen." canonical_url: "https://robocitrus.com/blog/rest-vs-graphql" last_updated: "2026-07-19T00:11:58.546Z" --- REST oder GraphQL? Wenn du gerade eine App oder ein Backend planst, ist das eine der ersten Fragen, die auftaucht. Beide Ansätze haben ihre Daseinsberechtigung -- und beide können die falsche Wahl sein, wenn du sie im falschen Kontext einsetzt. Ich zeige dir, wann du was brauchst. --- ## Kurz zusammengefasst Bevor wir ins Detail gehen, hier die beiden Ansätze im Schnellvergleich:
Kriterium REST GraphQL
Architektur Ressourcen-orientiert, mehrere Endpunkte Ein einziger Endpunkt, Query-basiert
Datenabfrage Server bestimmt die Struktur Client bestimmt die Struktur
Lernkurve Niedrig Mittel bis hoch
Caching Einfach (HTTP-Caching) Komplex (Client-seitig)
Over-Fetching Häufig Kein Problem
Tooling Überall verfügbar Wachsendes Ökosystem
Echtzeit Polling oder WebSockets separat Subscriptions eingebaut
Falls du noch nicht genau weißt, was eine API überhaupt ist: Schau dir zuerst meinen Artikel [Was ist eine API?](/blog/was-ist-eine-api) an. --- ## Was ist REST? REST steht für **Representational State Transfer** und ist seit über 20 Jahren der Standard für Web-APIs. Das Prinzip ist simpel: Jede Ressource hat eine eigene URL, und du nutzt HTTP-Methoden wie GET, POST, PUT und DELETE, um damit zu arbeiten. Ein REST Interface Beispiel: Du willst Nutzerdaten abrufen. Dann schickst du einen GET-Request an einen bestimmten Endpunkt: ```text GET /api/users/123 ``` Der Server antwortet mit einem JSON-Objekt, das alle Daten zu diesem Nutzer enthält. Willst du alle Blog-Posts? Anderer Endpunkt: ```text GET /api/posts ``` Willst du einen neuen Post erstellen? Gleicher Endpunkt, andere Methode: ```text POST /api/posts ``` Das Schöne an REST: Es nutzt Standards, die jeder Webentwickler kennt. HTTP-Methoden, Statuscodes, URLs -- nichts davon ist neu. Die Lernkurve ist flach, die Dokumentation riesig, und so gut wie jede Programmiersprache hat REST-Support eingebaut. REST ist das, was die meisten APIs im Internet nutzen. Wenn du eine [REST API](https://www.redhat.com/de/topics/api/what-is-a-rest-api) baust, baust du auf einem bewährten Fundament. --- ## Was ist GraphQL? GraphQL wurde 2015 von Meta (damals Facebook) veröffentlicht und verfolgt einen komplett anderen Ansatz. Statt vieler Endpunkte gibt es nur einen einzigen: `/graphql`. Der Client schickt eine Query und beschreibt exakt, welche Daten er braucht. Ein Beispiel: ```graphql query { user(id: "123") { name email posts { title createdAt } } } ``` Das Ergebnis? Du bekommst **exakt** das zurück, was du angefragt hast. Nicht mehr, nicht weniger. Kein Over-Fetching, keine unnötigen Daten. Das ist der große Unterschied: Bei REST bestimmt der **Server**, welche Daten in einer Response enthalten sind. Bei GraphQL bestimmt der **Client**. Klingt erstmal nach einem kleinen Detail, verändert aber die gesamte Architektur deiner Anwendung. GraphQL hat außerdem ein Typsystem eingebaut. Du definierst ein Schema, und sowohl Client als auch Server wissen genau, welche Daten in welchem Format existieren. Das macht die Entwicklung typsicher und die Dokumentation generiert sich quasi von selbst. --- ## SOAP kurz erklärt Bevor wir zum direkten Vergleich REST vs GraphQL kommen, ein kurzer Abstecher: Du stolperst vielleicht auch über SOAP, besonders wenn du nach **SOAP vs REST vs GraphQL** suchst. SOAP (Simple Object Access Protocol) ist der Vorgänger von REST und nutzt XML statt JSON. Es ist extrem strukturiert, hat eingebaute Fehlerbehandlung und wird heute hauptsächlich in Legacy-Systemen, Banken und Versicherungen eingesetzt. **Meine ehrliche Meinung:** Für neue Projekte in 2026 ist SOAP in den allermeisten Fällen die falsche Wahl. Zu verbose, zu komplex, zu wenig Developer-freundlich. Wenn du nicht gezwungen bist, ein SOAP-Interface anzubinden (weil dein Kunde ein altes System hat), bleib bei REST oder GraphQL. Kurz gesagt: **SOAP ist der Dinosaurier, REST der Platzhirsch, GraphQL der Herausforderer.** --- ## REST vs GraphQL: Der direkte Vergleich Jetzt wird's konkret. Hier die beiden API-Architekturen im Detail gegenübergestellt: ### Performance **REST:** Einzelne Endpunkte liefern feste Datenstrukturen. Für eine komplexe Ansicht brauchst du oft mehrere Requests (z.B. erst den Nutzer laden, dann seine Posts, dann die Kommentare). Das nennt sich Under-Fetching. **GraphQL:** Ein einziger Request kann verschachtelte Daten liefern. Nutzer, Posts und Kommentare in einem Rutsch. Weniger Netzwerk-Roundtrips, aber die Server-seitige Verarbeitung kann komplexer sein. **Fazit:** GraphQL gewinnt bei komplexen, verschachtelten Daten. REST ist effizienter bei einfachen CRUD-Operationen. ### Flexibilität **REST:** Die API-Struktur ist vom Server vorgegeben. Wenn das [Frontend](/blog/frontend-vs-backend) andere Daten braucht als das Backend liefert, musst du entweder einen neuen Endpunkt bauen oder den bestehenden anpassen. **GraphQL:** Der Client bestimmt die Datenstruktur. Verschiedene Frontends (Web, Mobile, Smart TV) können unterschiedliche Queries an dieselbe API schicken. **Fazit:** GraphQL ist deutlich flexibler, besonders bei mehreren Clients. ### Lernkurve **REST:** Wenn du HTTP verstehst, verstehst du REST. GET, POST, PUT, DELETE -- fertig. Die Konzepte sind intuitiv und es gibt unzählige Tutorials. **GraphQL:** Neues Paradigma, neue Syntax, neues Typsystem. Queries, Mutations, Subscriptions, Resolvers, Schema Definition Language -- da kommt einiges auf dich zu. **Fazit:** REST ist deutlich einfacher zu lernen. ### Caching **REST:** Weil jede Ressource eine eigene URL hat, funktioniert HTTP-Caching out-of-the-box. Browser, CDNs, Reverse Proxies -- alle können REST-Responses cachen. **GraphQL:** Alle Requests gehen an denselben Endpunkt mit POST. Standard-HTTP-Caching funktioniert nicht. Du brauchst Client-seitige Lösungen wie Apollo Client oder urql. **Fazit:** Caching ist bei REST deutlich einfacher. ### Echtzeit-Daten **REST:** Kein eingebauter Mechanismus. Du musst WebSockets, Server-Sent Events oder Polling separat implementieren. **GraphQL:** Subscriptions sind Teil der Spezifikation. Du kannst Echtzeit-Updates direkt über deine GraphQL-API abonnieren. **Fazit:** GraphQL hat hier die Nase vorn -- zumindest aus Architektur-Sicht. ### Tooling **REST:** Postman, Swagger/OpenAPI, curl -- die Tools sind etabliert und überall verfügbar. Jede IDE hat REST-Support. **GraphQL:** GraphiQL, Apollo DevTools, Playground -- das Tooling ist gut, aber kleiner. Der integrierte Schema Explorer ist allerdings ein echtes Highlight. **Fazit:** REST hat mehr Tools, GraphQL hat bessere Introspection. ### Over-Fetching und Under-Fetching **REST:** Ein klassisches REST Interface Beispiel: Du fragst den `/users/123`-Endpunkt ab und bekommst 30 Felder zurück, obwohl du nur Name und E-Mail brauchst. Das ist Over-Fetching. Oder du brauchst zusätzlich die Posts des Nutzers und musst einen zweiten Request machen -- Under-Fetching. **GraphQL:** Existiert nicht. Du fragst exakt das ab, was du brauchst. **Fazit:** GraphQL löst das Over-Fetching/Under-Fetching Problem elegant. --- ## REST API Beispiel Hier ein konkretes RESTful Interface Beispiel. Du willst einen Nutzer mit seinen letzten Blog-Posts abrufen: **Request 1 -- Nutzerdaten:** ```bash curl -X GET https://api.example.com/users/123 \ -H "Authorization: Bearer dein-token" ``` **Response:** ```json { "id": 123, "name": "Max Mustermann", "email": "max@example.com", "avatar": "https://api.example.com/avatars/123.webp", "role": "admin", "createdAt": "2024-03-15T10:30:00Z", "lastLogin": "2026-02-11T18:45:00Z", "settings": { "theme": "dark", "language": "de", "notifications": true } } ``` **Request 2 -- Posts des Nutzers:** ```bash curl -X GET https://api.example.com/users/123/posts?limit=3 \ -H "Authorization: Bearer dein-token" ``` **Response:** ```json { "data": [ { "id": 456, "title": "Mein erster Post", "excerpt": "Ein kurzer Einblick...", "createdAt": "2026-02-10T14:00:00Z" }, { "id": 457, "title": "REST APIs verstehen", "excerpt": "Eine Einführung...", "createdAt": "2026-02-11T09:00:00Z" } ], "meta": { "total": 24, "page": 1, "limit": 3 } } ``` Zwei Requests, und du bekommst bei Request 1 noch Felder wie `settings`, `avatar` und `lastLogin`, die du vielleicht gar nicht brauchst. Klassisches Over-Fetching. --- ## GraphQL Beispiel Die gleiche Abfrage mit GraphQL -- ein einziger Request: **Query:** ```graphql query GetUserWithPosts { user(id: "123") { name email posts(limit: 3) { title excerpt createdAt } } } ``` **Response:** ```json { "data": { "user": { "name": "Max Mustermann", "email": "max@example.com", "posts": [ { "title": "Mein erster Post", "excerpt": "Ein kurzer Einblick...", "createdAt": "2026-02-10T14:00:00Z" }, { "title": "REST APIs verstehen", "excerpt": "Eine Einführung...", "createdAt": "2026-02-11T09:00:00Z" } ] } } } ``` Ein Request, exakt die Daten, die du brauchst. Kein Over-Fetching, kein Under-Fetching. Das ist der Charme von GraphQL. --- ## Wann REST, wann GraphQL? Nach vielen Projekten mit beiden Ansätzen, hier meine Entscheidungshilfe: **Wähle REST wenn:** - Du ein einfaches CRUD-Backend baust - Dein Team wenig API-Erfahrung hat - Du starkes HTTP-Caching brauchst (z.B. für öffentliche APIs) - Du eine Microservice-Architektur mit klaren Ressourcen hast - Du schnell starten willst, ohne viel Setup - Du eine öffentliche API für Dritte anbietest **Wähle GraphQL wenn:** - Mehrere Clients (Web, iOS, Android) unterschiedliche Daten brauchen - Deine Datenstrukturen stark verschachtelt sind - Over-Fetching ein echtes Performance-Problem ist (z.B. bei mobilen Apps mit schwachem Netz) - Du ein komplexes Dashboard oder eine datenintensive App baust - Dein Frontend-Team unabhängig vom Backend arbeiten soll - Du Echtzeit-Features über Subscriptions brauchst **Und manchmal ist die Antwort: Beides.** Es spricht nichts dagegen, REST für einfache CRUD-Endpunkte zu nutzen und GraphQL für komplexe Datenabfragen. Viele große Projekte fahren diese hybride Strategie. --- ## Meine Empfehlung für App-Projekte Ich baue hauptsächlich Apps mit Flutter und arbeite viel mit verschiedenen Backend-Architekturen. Hier meine ehrliche Einschätzung für 2026: **Für die meisten Projekte: REST.** Und zwar aus einem einfachen Grund -- Einfachheit. REST ist battle-tested, jeder Entwickler versteht es, und es gibt Tools für alles. Wenn du ein [Backend für deine App](/blog/so-funktioniert-das-backend-meiner-production-app) baust, ist REST in 90% der Fälle die richtige Wahl. **Wann ich zu GraphQL greife:** Wenn ich ein Projekt habe, bei dem verschiedene Clients (Web-Dashboard, Mobile App, Admin Panel) auf dieselben Daten zugreifen, aber jeweils unterschiedliche Ansichten brauchen. Da spielt GraphQL seine Stärken aus. **Was ich nicht empfehle:** GraphQL wählen, nur weil es "modern" klingt. Die zusätzliche Komplexität muss sich durch einen konkreten Vorteil rechtfertigen. Wenn dein REST-Backend gut strukturiert ist und dein Client genau eine App ist, brauchst du kein GraphQL. Und vergiss nicht: Die API-Architektur ist nur ein Teil des Puzzles. Genauso wichtig ist, wie dein [Frontend mit dem Backend kommuniziert](/blog/frontend-vs-backend) und wie dein Backend insgesamt aufgebaut ist. --- ## Häufig gestellte Fragen Nicht automatisch. GraphQL kann weniger Netzwerk-Roundtrips brauchen, weil du verschachtelte Daten in einem Request abfragst. Aber die Server-seitige Verarbeitung einer komplexen GraphQL-Query kann aufwendiger sein als ein simpler REST-Call. Die GraphQL vs REST Performance hängt stark vom Anwendungsfall ab. Ja, und du musst nicht alles auf einmal umstellen. Viele Teams setzen GraphQL als Gateway vor ihre bestehenden REST-APIs. So kannst du schrittweise migrieren, ohne das Backend komplett neu zu bauen. Du brauchst eine GraphQL-Server-Bibliothek (z.B. Apollo Server, GraphQL Yoga, Mercurius), aber die laufen auf jedem gängigen Server-Framework. Node.js, Python, Go, Dart -- es gibt Implementierungen für quasi jede Sprache. GraphQL hat Vorteile bei mobilen Apps, weil du exakt die Daten abrufst, die du brauchst. Weniger Daten = weniger Bandbreite = schnellere Ladezeiten. Aber wenn deine REST-API gut designt ist und du wenige Endpunkte brauchst, ist der Unterschied minimal. Nein. REST ist nach wie vor der Standard und wird es auch 2026 bleiben. GraphQL ist eine Alternative für bestimmte Anwendungsfälle, kein Ersatz. Beide Technologien werden parallel existieren -- ähnlich wie SQL und NoSQL-Datenbanken.