REST vs. GraphQL: was passt zu deinem Projekt?

Debatten über REST vs. GraphQL enden oft in Architektur-Grabenkämpfen, was nicht hilfreich ist, wenn du tatsächlich entscheiden musst, was du baust. Beide sind ausgereifte, gut unterstützte Ansätze — der richtige hängt von deiner Datenform, deinen Client-Typen und deinem Team ab, nicht davon, was gerade angesagter ist.

Wie sie sich konkret unterscheiden

REST stellt feste, ressourcenbasierte Endpunkte bereit und stützt sich auf HTTP-Standardsemantik, was Caching auf CDN-Ebene einfach macht. GraphQL stellt einen einzigen Endpunkt bereit, bei dem der Client in einer Anfrage genau die Form der benötigten Daten angibt — und vermeidet so sowohl das Über- als auch das Unterabfragen, das REST erzeugen kann, wenn ein Bildschirm Daten aus mehreren Ressourcen gleichzeitig braucht.

Wo REST weiterhin gewinnt

Einfachheit, breite Tool-Unterstützung und die Möglichkeit, auf HTTP-/CDN-Ebene aggressiv zu cachen, machen REST zur besseren Standardwahl für einfache CRUD-APIs, öffentliche APIs mit vorhersehbaren Nutzern und Teams, die die niedrigstmögliche Lernkurve wollen.

Wo GraphQL seine Komplexität rechtfertigt

GraphQL zahlt sich aus, wenn das Frontend komplexe, verschachtelte Daten aus mehreren Ressourcen in einer einzigen Ansicht braucht — ein Dashboard, das aus mehreren Datenquellen zieht, ist der klassische Fall. Es hilft auch, wenn du mehrere sehr unterschiedliche Client-Typen (eine mobile App und eine Web-App mit unterschiedlichen Datenanforderungen) von einem Backend aus bedienen und wenn die Reduzierung von Round-Trips bei langsameren Netzwerken wichtig ist.

Ein einfacher Entscheidungsrahmen

Einfaches CRUD, eine öffentliche API oder ein kleines Team, das neu im API-Design ist — wähl REST. Komplexe verschachtelte Abfragen, mehrere Frontends mit unterschiedlichen Datenformen oder ein schnell arbeitendes Frontend-Team, das flexibel ohne Backend-Änderungen abfragen möchte — GraphQL rechtfertigt seinen Mehraufwand. Viele Produkte kombinieren am Ende beides: REST für einfache Ressourcen, eine GraphQL-Schicht dort, wo Aggregation wirklich hilft — so sieht auch der Großteil unserer API- und Integrationsarbeit aus.

Die Caching-Asymmetrie ist der Teil, den du vor der Festlegung verstanden haben solltest, denn sie ist strukturell und keine Frage des Aufwands. HTTP-Caching schlüsselt nach Methode und URL, also bekommt REST geteilte Caches, CDN-Knoten und bedingte Anfragen praktisch geschenkt. GraphQL schickt die meisten Operationen als POST an einen einzigen Endpunkt, den diese Schichten nicht cachen können — gleichwertiges Caching muss also innerhalb der Anwendung neu gebaut werden. Das GraphQL-Projekt dokumentiert das offen, statt es zu verschweigen, und verweist auf Persisted Queries und Caches pro Feld als Antwort.

Was dich der sichere Betrieb von GraphQL kostet

Der Vergleich endet meist bei der Abfragesprache, aber die Betriebsrechnung ist der Punkt, an dem sich beide wirklich trennen. Ein REST-Endpunkt hat einen halbwegs bekannten schlimmsten Fall: Er tut eine Sache, und du kannst ihn per URL rate-limiten. Ein GraphQL-Endpunkt nimmt Abfragen entgegen, die niemand in deinem Team geschrieben hat — sein schlimmster Fall ist also alles, was eine fremde Person zusammenbauen kann. Und die OWASP-Empfehlung sagt unverblümt, dass die nötigen Schutzmechanismen nicht mitgeliefert werden.

Konkret sind das vier Arbeitspakete, die REST nie von dir verlangt. Tiefenbegrenzung, die GraphQL nicht nativ unterstützt und die du ergänzen musst. Kostenanalyse der Abfrage, die dem Auflösen jedes Feldes Kosten zuweist, damit eine teure Abfrage abgelehnt werden kann, bevor sie läuft. Schutz gegen Batching- und Aliasing-Missbrauch, bei dem viele Objektanfragen in einem einzigen Aufruf zusammenfallen, der Nutzer, E-Mail-Adressen und IDs aufzählen kann und für dein Rate-Limit wie für deine WAF nach einer harmlosen Anfrage aussieht. Und Introspection in Produktion abzuschalten, was OWASP für alles öffentlich Erreichbare systemweit empfiehlt. Nichts davon ist für sich schwer. Zusammen ist es Arbeit, die ins Angebot gehört und nicht hinterher entdeckt werden sollte.

Quellen

Das oben beschriebene technische Verhalten stammt aus diesen primären Spezifikationen und Dokumentationen, geprüft im August 2026. Die Hinweise zur Betriebssicherheit stammen von OWASP. Der Entscheidungsrahmen ist unserer.

• GraphQL — Learn GraphQL ↗

  Die offizielle Einführung: ein einzelner Endpunkt, vom Client bestimmte Antwortform und die projekteigene Dokumentation von Caching und Query-Komplexität als die Bereiche, die bewusstes Design verlangen.

• GraphQL Foundation — GraphQL Specification ↗

  Die normative Spezifikation hinter Typsystem, Schema-Introspektion und Ausführungssemantik — der Grund, warum GraphQL-Tooling über Implementierungen hinweg konsistent ist.

• MDN Web Docs — HTTP caching ↗

  Wie geteilte und private Caches nach Methode und URL schlüsseln, und warum Cachebarkeit dadurch für REST-typische GETs praktisch gratis ist und für einen einzelnen POST-Endpunkt Handarbeit bleibt.

• RFC 9110 — HTTP Semantics ↗

  Der Standard, der die Methodensemantik, Statuscodes und bedingten Anfragen definiert, auf die sich REST stützt, statt sie neu zu erfinden.

• OWASP — GraphQL Cheat Sheet ↗

  Tiefenbegrenzung wird von GraphQL nicht nativ unterstützt und muss ergänzt werden; die Kostenanalyse weist Kosten pro Feld zu; Batching und Aliasing können Objekte aufzählen und dabei Rate-Limits und WAFs umgehen; Introspection sollte in Produktion systemweit deaktiviert sein.