REST API oder GraphQL: Was passt zum Projekt?
Ein Kundenportal zeigt Vertragsdaten, Dokumente und individuelle Angebote. Die Website benötigt gleichzeitig redaktionelle Inhalte aus dem CMS, eine App soll dieselben Daten nutzen, und später kommt vielleicht ein weiteres Frontend hinzu. Spätestens dann stellt sich die Frage: REST API oder GraphQL? Die Antwort entscheidet nicht nur über einzelne Endpunkte, sondern über Wartbarkeit, Berechtigungen, Performance und den Aufwand im laufenden Betrieb.
Beide Ansätze sind bewährt. REST ist seit Jahren ein tragfähiger Standard für Webanwendungen und Integrationen. GraphQL bietet mehr Flexibilität bei komplexen Datenabfragen. Entscheidend ist deshalb nicht, welche Technologie moderner wirkt, sondern welche Anforderungen das konkrete System langfristig erfüllen muss.
REST API oder GraphQL: Die grundlegende Entscheidung
Eine REST API organisiert Daten und Funktionen typischerweise über klar abgegrenzte Ressourcen. Für Beiträge, Produkte oder Kundendaten gibt es jeweils eigene Endpunkte. Die Anwendung ruft diese mit bekannten HTTP-Methoden wie GET, POST, PATCH oder DELETE auf. Das Prinzip ist leicht zu verstehen, gut dokumentierbar und in praktisch jeder Entwicklungsumgebung etabliert.
GraphQL verfolgt einen anderen Ansatz. Statt mehrere feste Endpunkte aufzurufen, stellt eine Anwendung meist Anfragen an einen zentralen Endpunkt. Das Frontend beschreibt dabei präzise, welche Felder und Beziehungen es benötigt. Es kann beispielsweise einen Teaser, das Titelbild, die Autorin und drei verwandte Inhalte in einer Anfrage abrufen - ohne für jeden Teil eigene Requests zusammenzustellen.
Der Unterschied ist relevant, aber kein Selbstzweck. REST setzt auf eine klar definierte Schnittstelle, die der Server vorgibt. GraphQL überlässt dem Client stärker die Auswahl der Daten. Das kann Entwicklungsprozesse beschleunigen, verlangt aber ein sorgfältiges Datenmodell und klare Regeln für Sicherheit und Betrieb.
Wann eine REST API die bessere Wahl ist
REST passt besonders gut, wenn Prozesse und Ressourcen eindeutig sind. Ein Formular übermittelt eine Anfrage, ein Shop aktualisiert den Warenbestand oder ein CRM stellt Kundendaten für ein internes System bereit. In solchen Fällen sind feste Endpunkte häufig einfacher zu testen, zu versionieren und abzusichern.
Auch für klassische CMS-Projekte bietet REST oft Vorteile. Redaktionsinhalte, Navigationen, Mediatheken oder Suchergebnisse lassen sich mit nachvollziehbaren Endpunkten bereitstellen. Wenn ein TYPO3-System primär eine Website versorgt und nur wenige externe Anwendungen angebunden werden, ist die zusätzliche Flexibilität von GraphQL nicht zwingend notwendig.
Ein weiterer praktischer Punkt ist das Caching. GET-Anfragen auf REST-Endpunkte lassen sich mit etablierten Mechanismen gut im Browser, über einen Reverse Proxy oder ein Content Delivery Network zwischenspeichern. Das ist gerade bei reichweitenstarken Websites mit vielen wiederkehrenden Abrufen ein klarer Vorteil. Natürlich ist auch GraphQL cachebar, die Umsetzung ist jedoch oft anspruchsvoller, weil sich Abfragen stärker unterscheiden können.
REST ist außerdem eine gute Wahl, wenn mehrere externe Partner oder Dienstleister mit der Schnittstelle arbeiten. Eine sauber dokumentierte API mit stabilen URLs, klaren Request- und Response-Formaten sowie nachvollziehbaren Fehlercodes reduziert Abstimmungsaufwand. Für viele Integrationen ist diese Vorhersehbarkeit wertvoller als maximale Abfragefreiheit.
REST braucht eine gute Endpunktplanung
Die verbreitete Kritik an REST lautet: Das Frontend erhält manchmal zu viele oder zu wenige Daten. Für eine Seite werden mehrere Requests nötig, oder ein Endpunkt liefert umfangreiche Informationen, von denen nur ein kleiner Teil benötigt wird. Dieses Overfetching und Underfetching kommt vor, ist aber nicht unvermeidlich.
Eine API lässt sich gezielt auf Anwendungsfälle zuschneiden. Statt ausschließlich generische Endpunkte wie `/articles/123` bereitzustellen, kann es sinnvoll sein, einen Endpunkt für eine konkrete Ansicht zu definieren. Wichtig ist, nicht für jede kleine Frontend-Änderung neue Spezialendpunkte zu schaffen. Eine gute REST-Architektur findet die Balance zwischen Wiederverwendbarkeit und klaren Anforderungen.
Wann GraphQL seine Stärken ausspielt
GraphQL wird interessant, wenn viele Datenquellen, komplexe Beziehungen oder unterschiedliche Ausgabekanäle zusammenkommen. Ein Headless-CMS kann Inhalte für eine Website, eine mobile App, ein Kundenportal und digitale Displays bereitstellen. Diese Anwendungen benötigen nicht dieselben Felder und nicht dieselben Datenmengen. Mit GraphQL können sie ihre Abfragen passgenau formulieren.
Das ist besonders hilfreich bei modularen Frontends. Moderne Anwendungen bestehen oft aus vielen Komponenten: Bühne, Teaser, Produktvergleich, Kontaktbereich, Personalisierung und weitere dynamische Elemente. Statt für jede Komponente eigene Endpunkte zu kombinieren, kann das Frontend die benötigten Daten strukturiert abfragen.
GraphQL kann auch die Weiterentwicklung einer Plattform erleichtern. Neue Felder im Schema lassen sich ergänzen, ohne bestehende Abfragen zwangsläufig zu verändern. Bei REST werden für größere Änderungen häufiger neue API-Versionen notwendig. Das ist nicht grundsätzlich schlecht, erfordert aber mehr Koordination zwischen Backend, Frontend und angebundenen Systemen.
Flexibilität erfordert klare Grenzen
Die Stärke von GraphQL ist zugleich seine anspruchsvollste Seite. Wenn Clients sehr tief verschachtelte oder besonders umfangreiche Abfragen stellen dürfen, können Datenbank und Server unnötig belastet werden. Eine schlecht begrenzte Anfrage kann deutlich mehr Ressourcen verbrauchen als erwartet.
Deshalb gehören Tiefenbegrenzungen, Komplexitätsanalysen, Abfragelimits und ein durchdachtes Berechtigungskonzept von Beginn an dazu. Auch das Caching muss bewusst geplant werden. Eine allgemeine Antwort für alle GraphQL-Anfragen zwischenspeichern zu wollen, funktioniert selten. Oft ist ein Zusammenspiel aus serverseitigem Caching, Caching einzelner Resolver und clientseitiger Normalisierung sinnvoll.
Für Unternehmen bedeutet das: GraphQL ist keine Abkürzung zu einer besseren Architektur. Es lohnt sich, wenn die Flexibilität tatsächlich genutzt wird und das Entwicklungsteam die Schnittstelle dauerhaft betreuen kann. Für eine überschaubare Website mit klaren Datenstrukturen kann der zusätzliche Aufwand unverhältnismäßig sein.
Sicherheit und Berechtigungen nicht nachträglich lösen
Unabhängig von der Technologie darf eine API nur die Daten liefern, die der jeweilige Nutzer oder das jeweilige System sehen und bearbeiten darf. Das klingt selbstverständlich, wird aber bei komplexen Datenmodellen schnell anspruchsvoll. Besonders in Kundenportalen, Intranets oder Systemen mit personenbezogenen Daten reicht es nicht, den Zugriff lediglich am Endpunkt oder am zentralen GraphQL-Gateway zu prüfen.
Berechtigungen müssen auf Daten- und Aktionsebene greifen. Darf eine Person diesen Datensatz sehen? Welche Felder sind sichtbar? Darf sie den Status ändern oder nur lesen? Bei GraphQL betrifft das zusätzlich jede mögliche Abfrage und jedes auflösende Element. Bei REST muss die Prüfung konsequent für alle Endpunkte und HTTP-Methoden umgesetzt werden.
Hinzu kommen Authentifizierung, Protokollierung, Rate Limits, Eingabevalidierung und ein verlässliches Fehlerhandling. Gerade bei langfristig betriebenen Webplattformen sind diese Themen wichtiger als die Frage, ob eine Abfrage einen oder drei Requests erzeugt. Eine API ist Teil der Angriffsfläche und sollte wie ein eigenständiges Produkt behandelt werden.
Das CMS und die Systemlandschaft entscheiden mit
Bei CMS-Projekten ist die API-Strategie eng mit der gewünschten Architektur verbunden. Eine klassisch gerenderte TYPO3-Website benötigt oft gar keine umfassende öffentliche Content-API. Hier kann es sinnvoller sein, nur dort Schnittstellen bereitzustellen, wo sie einen konkreten Nutzen haben: etwa für eine Suche, einen geschützten Bereich oder eine angebundene App.
Bei einem Headless-Ansatz sieht die Lage anders aus. Wenn Inhalte zentral gepflegt und über mehrere Frontends ausgespielt werden, wird die API zum Kern der Plattform. Dann lohnt es sich, Datenmodelle, Vorschauprozesse, Mehrsprachigkeit, Medienverwaltung und Rechte früh gemeinsam zu planen. Ob REST oder GraphQL gewählt wird, sollte aus diesen Anforderungen folgen - nicht aus einer Technologiepräferenz.
Auch bestehende Systeme spielen eine Rolle. Viele Drittsysteme bringen REST-Schnittstellen mit, etwa ERP-, PIM-, CRM- oder Payment-Lösungen. Es ist häufig sinnvoll, diese nicht zwanghaft durch GraphQL zu ersetzen. Eine Anwendung kann intern und extern unterschiedliche Schnittstellen nutzen. Beispielsweise kann ein Backend REST-Dienste integrieren und nach außen eine GraphQL-Schicht für mehrere Frontends anbieten. Diese Architektur lohnt sich allerdings nur bei ausreichend komplexen Anforderungen.
Eine belastbare Entscheidung treffen
Vor der technischen Auswahl sollten Unternehmen zuerst festhalten, welche Anwendungen die Daten nutzen, wie häufig sich Anforderungen ändern und welche Daten besonders geschützt werden müssen. Ebenso wichtig sind erwartete Zugriffszahlen, Anforderungen an Caching, die Erfahrung des Teams und der geplante Betreuungszeitraum.
REST ist meist die wirtschaftliche und verlässliche Wahl für klar abgegrenzte Integrationen, klassische Webprojekte und stabile Prozesse. GraphQL zeigt seine Vorteile bei datenreichen Plattformen, mehreren Clients und Frontends mit sehr unterschiedlichen Informationsbedarfen. Ein hybrider Ansatz kann sinnvoll sein, wenn er ein konkretes Problem löst - nicht, weil zwei Technologien grundsätzlich besser klingen als eine.
Die beste Schnittstelle ist am Ende die, die auch nach dem Launch verständlich dokumentiert, sicher betrieben und ohne unnötige Reibung weiterentwickelt werden kann. Wer diese Fragen früh in Architektur, Datenmodell und Betrieb einbezieht, schafft eine Grundlage, die mit dem digitalen Geschäft mitwachsen kann.
