GraphQL oder REST: Wie Sie 2026 die richtige API wählen

Wählen Sie REST, wenn Ihre Daten einfach sind, sich Ihre Clients ähnlich verhalten und Sie das vertrauteste Werkzeug wollen. Wählen Sie GraphQL, wenn viele unterschiedliche Clients jeweils andere Ausschnitte derselben Daten brauchen oder wenn eine Ansicht Daten aus mehreren Quellen zusammenzieht. Für die meisten jungen Produkte ist REST die bessere Wahl. Die meisten Produkte, die über REST hinauswachsen, tun das wegen der Vielfalt ihrer Clients, nicht wegen des Datenverkehrs.

Der Rest dieses Artikels zeigt, woher diese Faustregel kommt, was die Messungen sagen und was Sie jede Variante im Alltag kostet. Wir bauen in Zürich Web-Apps und Plattformen, deshalb kommt auch die Praxis zur Sprache: Was Sie klären sollten, bevor Sie sich festlegen.

Kurz zusammengefasst

• REST ist ein Architekturstil rund um Ressourcen und URLs. GraphQL ist eine Abfragesprache mit typisiertem Schema, die meist über einen einzigen Endpunkt läuft.
• GraphQL beseitigt zu viele und zu wenige mitgelieferte Daten und passt zu vielfältigen Clients und mehreren Datenquellen. REST ist einfacher, lässt sich leichter cachen und passt zu kleineren Anwendungen.
• In einer wissenschaftlichen Studie hatte GraphQL bei den meisten Endpunkten tiefere durchschnittliche Antwortzeiten, REST skalierte dafür bei hoher Parallelität besser.
• GraphQL verlagert Arbeit auf den Server: Kostengrenzen für Abfragen, das N+1-Problem und das Caching wollen bewusst entworfen sein.
• Für ein erstes Produkt mit einem einzigen Web-Client beginnen Sie mit REST. Wechseln Sie zu GraphQL, wenn sich die Endpunkte wegen der Client-Vielfalt vermehren.

Was die beiden tatsächlich sind

Es handelt sich nicht um gleichartige Dinge, und genau deshalb geraten Vergleiche oft durcheinander. REST ist ein Architekturmuster. GraphQL ist eine Abfragesprache samt Laufzeitumgebung. Eine REST-API stellt Ressourcen unter URLs wie /orders/42 bereit, und die HTTP-Methode bestimmt, was damit geschieht. Eine GraphQL-API stellt ein Schema bereit, und der Client sendet eine Abfrage, die genau beschreibt, in welcher Form er die Daten zurückhaben will.

Sie haben mehr gemeinsam, als die Debatten vermuten lassen. Laut der AWS AppSync documentation folgen beide einem Client-Server-Modell, beide sind zustandslos und beide laufen typischerweise über HTTP. Sie können in beiden Stilen eine schlechte API bauen, und in beiden eine gute.

Eine brauchbare Kurzformel: Bei REST entscheidet der Server, was jeder Endpunkt zurückgibt. Bei GraphQL entscheidet der Client, was er braucht, innerhalb dessen, was das Schema erlaubt.

Der direkte Vergleich

Kriterium	REST	GraphQL
Grundidee	Ressourcen hinter vielen URLs	Ein Schema, meist ein Endpunkt
Datenform	Vom Server je Endpunkt festgelegt	Vom Client je Abfrage gewählt
Zu viele und zu wenige Daten	Häufig	Konstruktionsbedingt vermieden
Schema	Optional (zum Beispiel OpenAPI)	Erforderlich, streng typisiert
HTTP-Caching	Unkompliziert	Schwieriger, braucht Zusatzaufwand
Echtzeit	Long Polling oder Server-Sent Events	Subscriptions
Lernaufwand	Gering	Mittel
Passt am besten zu	Einfachen Daten, ähnlichen Clients, öffentlichen APIs	Vielen Clients, vielen Datenquellen, verschachtelten Daten

Die Zeilen ergeben sich aus denselben Abwägungen, die die nächsten Abschnitte einzeln erklären.

Datenabruf: zu viel, zu wenig und zu viele Anfragen

Das ist der Grund, weshalb es GraphQL gibt. Stellen Sie sich eine mobile Bestellansicht vor, die den Kundennamen, die letzten drei Bestellungen und deren Status braucht. Mit REST rufen Sie vielleicht /customers/7 auf, dann /customers/7/orders und dann pro Bestellung einen Status. Das ist zu wenig auf einmal: Die erste Antwort genügt nicht, also folgen weitere Anfragen. Gleichzeitig enthält jede Antwort wohl Felder, die die Ansicht gar nie zeigt, also zu viel auf einmal.

Eine University of Washington study on GraphQL and REST performance beschreibt genau das: REST kann zu beiden Problemen führen, während GraphQL die Clients festlegen lässt, was sie abrufen, und Daten aus mehreren Quellen in einer Anfrage bündeln kann. Die AWS-Dokumentation sagt dasselbe in praktischer Form: GraphQL senkt den Netzwerkaufwand, weil in einem einzigen Aufruf nur die angeforderten Daten zurückkommen.

Es gibt auch eine REST-Antwort darauf. Sie können für jede Ansicht eigene Endpunkte bauen oder Parameter annehmen, die Felder auswählen. Das funktioniert, nur bringt dann jeder neue Client zusätzliche Arbeit auf dem Server. An diesem Punkt beginnen Teams, über GraphQL nachzudenken: nicht weil REST langsam wäre, sondern weil die Zahl der Endpunkt-Varianten aus dem Ruder läuft.

Performance: was die Messungen sagen

Seien Sie skeptisch bei jedem Artikel, der behauptet, eines sei schlicht schneller. Die Forschenden der University of Washington haben beide Stile in mehreren Lastszenarien gemessen. Ergebnis: Apollo GraphQL hatte bei den meisten Endpunkten und Lastszenarien eine um 25 bis 67 % tiefere durchschnittliche Umlaufzeit als REST, während REST bei hoher Parallelität besser skalierte.

Lesen Sie das genau. Es ist eine Studie, ein Technologie-Stack und ein Satz Testbedingungen. Zwei vernünftige Schlüsse stützt sie trotzdem:

1. Für einen Client mit langsamer oder mobiler Verbindung helfen weniger Anfragen und kleinere Antworten, und darin ist GraphQL gut.
2. Ein GraphQL-Server leistet pro Anfrage mehr Arbeit, weil er jede Abfrage analysiert, prüft und auflöst. Bei hoher paralleler Last zeigt sich dieser Zusatzaufwand.

Für die meisten Schweizer KMU und Startups entscheidet keiner der beiden Effekte über das Projekt. Ihr Datenbankentwurf, Ihre Hosting-Region und Ihr Caching bewegen die Antwortzeiten stärker als der API-Stil. Wenn Sie für Ihr eigenes Produkt eine Antwort zur Performance brauchen, messen Sie einen realistischen Prototypen mit Ihren eigenen Daten, statt sich auf einen Benchmark zu verlassen.

Wie Echtzeit-Übertragung in der Praxis funktioniert, zeigt dieser Leitfaden zu REST and WebSocket data streams: Er beschreibt, wie eine Daten-API anfragebasierte Endpunkte mit laufenden Datenströmen kombiniert.

Caching: hier hat es REST leichter

REST nutzt die Mechanik des Webs selbst. Laut dem IBM’s comparison verwenden REST-APIs eTags und Last-Modified-Header, um Aufrufe zu cachen. Browser, CDNs und Proxys verstehen das ohne Zutun. Jede URL ist ein Cache-Schlüssel.

GraphQL schickt Abfragen meist an einen einzigen Endpunkt, oft als POST-Anfragen, womit das eingebaute HTTP-Caching grösstenteils entfällt. IBM hält fest, dass GraphQL schwieriger zu cachen sein kann, auch wenn persistierte Abfragen, Antwort-Caching und serverseitiges Caching helfen. Client-Bibliotheken wie Apollo Client speichern zudem normalisierte Objekte auf der Client-Seite zwischen, was das Problem im Browser entschärft.

Die praktische Folge: Wenn Ihr Produkt viele öffentliche, lesestarke Inhalte ausliefert, die ein CDN abfangen soll, ist REST der Weg mit weniger Aufwand. Wenn Ihr Verkehr überwiegend aus angemeldeten, personalisierten Daten besteht, fällt der Caching-Unterschied kaum ins Gewicht, denn diese Daten wären ohnehin nie in einem geteilten Cache gelandet.

Schema, Typisierung und Fehlerbehandlung

GraphQL verlangt ein streng typisiertes Schema, geschrieben in seiner eigenen Schema-Definitionssprache. Die AWS-Dokumentation weist darauf hin, dass der Dienst dadurch viele fehlerhafte Anfragen erkennt, bevor Ihr Code überhaupt läuft. Ein Client, der ein nicht existierendes Feld anfragt, erhält eine klare Abweisung. Das Schema speist ausserdem Dokumentation, Autovervollständigung und Code-Generierung, was Teams mit getrennten Frontend- und Backend-Entwickler:innen wirklich etwas bringt.

REST verlangt kein serverseitiges Schema. Sie können mit OpenAPI eines ergänzen, und viele Teams tun das, aber niemand zwingt Sie dazu. Ohne Schema leben Fehlerbehandlung und Validierung im umgebenden Code, und die Verträge zwischen Teams können auseinanderdriften.

Eine Eigenheit von GraphQL überrascht Neulinge: Eine Anfrage kann mit HTTP 200 ein Teilergebnis und zugleich eine Fehlerliste im Antwortkörper zurückgeben. Ihre Überwachung und Ihr Client-Code müssen also in die Antwort hineinschauen und nicht nur auf Statuscodes.

Aktualisierungen in Echtzeit

GraphQL kennt Subscriptions, einen eingebauten Weg, damit ein Client Aktualisierungen erhält, sobald sich Daten ändern. IBM weist darauf hin, dass REST kein Gegenstück dazu hat und meist auf Long Polling oder Server-Sent Events zurückgreift. In der Praxis laufen Subscriptions typischerweise über WebSockets, was eine zustandsbehaftete Verbindungsschicht bedeutet. Das ist echte Infrastruktur, die betrieben und skaliert werden will.

Sind Live-Aktualisierungen nur eine Nebenfunktion, etwa ein Zähler für Benachrichtigungen, ist eine REST-API mit Server-Sent Events oft einfacher. Sind Live-Daten das Produkt, wie bei Chat, gemeinsamem Bearbeiten oder Dashboards, denken Sie zuerst über den Übertragungsweg nach und erst danach über den Abfragestil.

Die Kosten, die GraphQL mitbringt

GraphQL verschiebt Komplexität vom Client auf den Server. Drei Punkte tauchen in fast jedem Projekt auf.

Das N+1-Problem

Ein GraphQL-Server löst jedes Feld über einen Resolver auf. Fragen Sie 50 Bestellungen samt zugehöriger Kundschaft ab, führt eine naive Umsetzung eine Abfrage für die Bestellungen aus und 50 weitere für die Kund:innen. Die GraphQL.org’s performance guidance nennt das N+1-Problem und empfiehlt Bündelung, zum Beispiel mit DataLoader. Es ist lösbar, aber jemand muss wissen, dass es zu lösen ist.

Teure Abfragen und Sicherheit

Weil die Clients die Abfrage schreiben, können sie eine sehr kostspielige schreiben. Das OWASP GraphQL Cheat Sheet warnt, dass teure Abfragen zu einer Dienstblockade führen können, und empfiehlt Tiefenbegrenzung, Mengenbegrenzung, Seitenweise Auslieferung, Zeitlimiten, Kostenanalyse für Abfragen und Begrenzung der Anfragerate. Es rät zudem, unsichere Voreinstellungen abzuschalten, etwa zu ausführliche Fehlermeldungen und Introspektion im Produktivbetrieb, und die Zugriffskontrolle sauber zu prüfen. Bei REST legt der Server fest, was jeder Endpunkt kosten darf, womit diese Problemklasse kleiner ausfällt.

Wissen im Team und Werkzeuge

Die meisten Entwickler:innen kennen REST bereits, und die Werkzeuge gibt es überall. IBM beobachtet, dass viele Organisationen weiterhin auf REST setzen, wegen der etablierten Werkzeuge und der Einfachheit, selbst dort, wo GraphQL eine starke Option wäre. Ein kleinerer Kreis an Fachleuten und eine steilere Lernkurve gehören zu den Kosten von GraphQL, und das zählt, wenn Sie in der Schweiz anstellen, wo erfahrene Entwickler:innen teuer und rar sind.

Wo gRPC hineinpasst

Wer zu diesem Thema sucht, stösst oft auf eine dritte Option. gRPC läuft über HTTP/2 und sendet kompakte Binärnachrichten, die in Protocol Buffers definiert sind, mit einem verbindlichen Schema in einer .proto-Datei. Ein comparison of REST, GraphQL and gRPC fasst die übliche Aufteilung zusammen: REST für öffentliche APIs und alles, was ein Browser direkt aufruft, GraphQL, wenn viele Clients unterschiedliche Ausschnitte derselben Daten brauchen, und gRPC zwischen internen Diensten, die Sie auf beiden Seiten kontrollieren.

Für eine typische Website oder Web-App ist gRPC nicht die erste Entscheidung. Relevant wird es, wenn Sie ein Backend in mehrere Dienste aufteilen, die viel miteinander sprechen.

Wann GraphQL passt und wann REST die bessere Wahl ist

Die Empfehlung von AWS ist eine gute Ausgangslage. REST passt zu kleineren Anwendungen mit weniger komplexen Datenbedürfnissen oder zu Clients, die Daten und Operationen auf ähnliche Weise nutzen. GraphQL passt zu knapper Bandbreite, mehreren Datenquellen oder unterschiedlichen Anfragen der Clients. Postman fasst die Abwägung so: Einfachheit und Standardisierung bei REST gegen Flexibilität und Effizienz bei GraphQL.

Übersetzen Sie das in Fragen zu Ihrem eigenen Produkt:

• Wie viele verschiedene Clients werden die API nutzen? Eine Web-App und eine mobile App mit ähnlichen Ansichten: REST. Eine Web-App, zwei mobile Apps, Partner-Anbindungen und ein Kiosk, jeweils mit anderen Bedürfnissen: GraphQL verdient einen Blick.
• Wie stark verschachtelt sind Ihre Daten? Flache Listen und einfache Datensätze passen zu REST. Tiefe Geflechte verknüpfter Objekte passen zu GraphQL.
• Führen Sie mehrere Backends zusammen? Eine GraphQL-Schicht vor CRM, ERP und Shop-System gibt den Frontend-Entwickler:innen eine einzige saubere Schnittstelle.
• Ist die API öffentlich? Öffentliche APIs für Dritte lassen sich als REST leichter dokumentieren, cachen und in der Anfragerate begrenzen.
• Wer wird sie betreuen? Besteht Ihr Team aus zwei Entwickler:innen und einer Agentur, gewinnt das einfachere Modell bei den Betriebskosten.
• Haben Sie viel Lesezugriff auf öffentliche Inhalte? Dann gewinnen REST und CDN-Caching.

Ein häufiger Mittelweg

Sie müssen sich nicht ein für alle Mal entscheiden. Viele Produkte behalten REST für einfache, cachebare Ressourcen und öffentliche Endpunkte und ergänzen später eine GraphQL-Schicht als Zugang für komplexe Frontends. Wenn Sie mit einer sauberen, gut dokumentierten REST-API samt OpenAPI-Schema starten, halten Sie sich diese Tür offen, ohne von Tag eins an für GraphQL zu bezahlen.

Was das für ein Startup oder KMU in der Schweiz bedeutet

Die Frage, die die meisten Gründer:innen stellen, lautet nicht, was besser sei, sondern was eine Neuentwicklung verhindert. Unsere ehrliche Antwort: Der API-Stil verursacht selten eine Neuentwicklung. Unklare Anforderungen, verhedderte Datenmodelle und Endpunkte für den Einzelfall tun das. Wählen Sie den Stil, den Ihr Team gut beherrscht, definieren Sie Ihr Datenmodell sorgfältig und dokumentieren Sie den Vertrag.

Zwei Fälle begegnen uns in unserer Arbeit häufig. Der erste ist ein neues MVP mit einem einzigen Web-Frontend: REST mit typisiertem Schema ist schnell gebaut und günstig zu übergeben. Der zweite ist ein Unternehmen, das einen bestehenden Shop, ein CRM und ein ERP in einem neuen Portal verbindet: Hier können eine GraphQL-Schicht oder eine schlanke Integrationsschicht mit eigens gebauten REST-Endpunkten beide funktionieren, und die richtige Entscheidung hängt davon ab, wie viele Frontends Sie in den nächsten zwei Jahren erwarten.

Wie wir Sie unterstützen

Wir sind ein kleines Zürcher Studio, und erfahrene Entwickler:innen bleiben vom ersten Gespräch bis zur Übergabe auf jedem Projekt. Die Entscheidung über die API treffen also die Menschen, die sie bauen und betreuen. Wir entwickeln Websites, Web- und Mobile-Apps, Plattformen und Systemintegrationen, und wir können eine bestehende API prüfen oder eine Migration planen. Wenn Sie vor der Festlegung eine zweite Meinung möchten, finden Sie hier unsere Preise und Zusammenarbeitsmodelle oder einen Blick auf aktuelle Projekte. Für die laufende Betreuung kostet unser Plan Run & monitor CHF 750 pro Monat, unser Plan Guidance für erfahrene technische Beratung CHF 799 pro Monat.

Häufige Fragen

Ist GraphQL besser als REST?

Generell ist keines von beiden besser. GraphQL ist stärker bei vielfältigen Clients, verschachtelten Daten und mehreren Quellen, während REST einfacher ist, sich leichter cachen lässt und von fast allen Entwickler:innen gut verstanden wird. Die richtige Wahl hängt von Ihren Clients, Ihren Daten und Ihrem Team ab.

Ist GraphQL schneller als REST?

Bei der einzelnen Anfrage oft, bei grosser Last nicht immer. In einer Studie der University of Washington hatte GraphQL bei den meisten Endpunkten tiefere durchschnittliche Antwortzeiten, während REST bei hoher Parallelität besser skalierte. Testen Sie Ihre eigene Last, bevor Sie entscheiden.

Was sind die wichtigsten Vor- und Nachteile von GraphQL?

Die Vorteile sind der punktgenaue Datenabruf, ein typisiertes Schema, weniger Anfragen hin und zurück und eingebaute Subscriptions. Die Nachteile sind schwierigeres HTTP-Caching, das N+1-Problem, die Notwendigkeit, teure Abfragen zu begrenzen, und eine steilere Lernkurve.

Kann ich GraphQL und REST zusammen nutzen?

Ja. Viele Teams behalten REST für einfache oder öffentliche Endpunkte und setzen GraphQL vor mehrere Dienste, wenn die Frontends komplex sind. So führen Sie GraphQL dort ein, wo es sich lohnt, ohne alles neu zu schreiben.

Quellen

• AWS AppSync documentation
• University of Washington study on GraphQL and REST performance
• IBM’s comparison
• GraphQL.org’s performance guidance
• OWASP GraphQL Cheat Sheet
• comparison of REST, GraphQL and gRPC
• Postman
• REST and WebSocket data streams