REST oder GraphQL — welche Schnittstelle?

Die REST-Schnittstelle.

In WordPress eingebaut, ohne Plugin verfügbar. Man ruft eine Adresse auf und bekommt die Daten eines Inhaltstyps zurück — Beiträge, Seiten, Medien, Kategorien, Benutzer. Jeder Inhaltstyp hat seine eigene Adresse.

Vorteile: keine zusätzliche Abhängigkeit, breite Unterstützung, gut zwischenspeicherbar, von jedem Entwickler sofort verstanden. Nachteile: Man bekommt immer das komplette Datenpaket, auch wenn man drei Felder braucht, und für zusammengesetzte Ansichten muss man mehrfach fragen (REST-API).

GraphQL.

Kommt über ein Plugin. Es gibt eine einzige Adresse, und in der Anfrage beschreibt man genau, welche Felder man haben will — auch über mehrere Ebenen hinweg. Die Antwort enthält exakt das und nichts weiter.

Vorteile: eine Anfrage statt vieler, keine überflüssigen Daten, das Schema ist selbstbeschreibend. Nachteile: zusätzliches Plugin, das mitgepflegt werden muss, schwerer zwischenzuspeichern, und mehr Einarbeitung.

Zu viel und zu wenig.

Zwei Begriffe, die den Unterschied erklären. Zu viel bedeutet: Man fragt einen Beitrag ab und bekommt den kompletten Datensatz mit allen Feldern, obwohl nur Titel und Bild gebraucht werden. Zu wenig bedeutet: Die erste Antwort reicht nicht, man muss nachfragen — etwa für die Kategorie oder das Beitragsbild.

Bei REST hat man beides. Praktisch relevant wird es vor allem bei Übersichtsseiten: Zwanzig Beiträge mit Bild, Kategorie und Autor sind bei REST schnell sechzig Anfragen. Bei GraphQL ist es eine.

Zu relativieren ist das bei statisch erzeugten Seiten: Wenn die Seiten ohnehin beim Veröffentlichen gebaut werden, merkt der Besucher von sechzig Anfragen nichts — es dauert nur der Bauvorgang länger. Bei vielen tausend Seiten wird genau das aber zum Problem.

Zahl der Anfragen.

Die letzte Zeile ist das stärkste Argument für GraphQL bei großen Projekten. Ein vollständiger Neubau, der mit REST eine Stunde dauert, läuft mit GraphQL oft in einem Bruchteil — und das ist der Unterschied zwischen praktikabel und nicht.

Eigene Felder.

Die meisten Projekte arbeiten mit eigenen Inhaltstypen und Zusatzfeldern. Beide Schnittstellen können die ausgeben, aber es muss eingerichtet werden (Custom Post Types).

Bei REST werden eigene Felder registriert und erscheinen dann im Datenpaket. Bei GraphQL müssen sie dem Schema bekannt gemacht werden; für die verbreiteten Feld-Plugins gibt es dafür fertige Erweiterungen.

Ein wichtiger Punkt für die Planung: Zusatzfelder sind nicht automatisch über die Schnittstelle sichtbar. Wer ein Feld-Plugin einsetzt, muss prüfen, ob es die gewählte Schnittstelle bedient — das ist eine der ersten Fragen vor der Technikentscheidung.

Zwischenspeicherung.

Ein Punkt für REST. Jede Adresse ist eindeutig, also lässt sich die Antwort auf jeder Ebene zwischenspeichern — im Browser, in einem vorgeschalteten Dienst, auf dem Server. Das ist einfach und wirkt sofort.

Bei GraphQL geht alles über eine Adresse, und die Anfrage steckt im Inhalt. Zwischenspeichern erfordert dann mehr Aufwand — entweder auf Anwendungsebene oder über gespeicherte Abfragen, die wieder eindeutige Adressen erzeugen.

Relativiert wird das bei statisch erzeugten Seiten: Dort liegen die fertigen Seiten beim Besucher an, und die Schnittstelle wird nur beim Bauen gefragt. Dann ist Zwischenspeicherung weniger wichtig (Caching).

Sicherheit.

Für beide gilt: Die Schnittstelle sollte nicht offen im Netz stehen. Praktisch heißt das, WordPress hinter einer eigenen Adresse zu betreiben und den Zugriff auf das Frontend zu beschränken.

Bei REST gibt der eingebaute Zugang standardmäßig mehr preis, als vielen bewusst ist — etwa die Liste der Benutzernamen. Das lässt sich einschränken und sollte es auch (WordPress absichern).

Bei GraphQL kommt eine Besonderheit dazu: Eine einzige Abfrage kann sehr tief verschachtelt sein und damit erhebliche Last erzeugen. Deshalb gehören Tiefenbegrenzung und Begrenzung der Abfragekosten eingerichtet — das ist kein Feinschliff, sondern Pflicht bei einer öffentlich erreichbaren Schnittstelle.

Werkzeuge.

GraphQL punktet bei der Entwicklungsarbeit. Das Schema ist selbstbeschreibend, es gibt eine eingebaute Oberfläche zum Ausprobieren von Abfragen, und Werkzeuge können daraus Typdefinitionen erzeugen — damit fallen Fehler schon beim Schreiben auf.

Bei REST fehlt das weitgehend. Man arbeitet mit der Dokumentation und probiert Adressen aus. Für kleine Projekte ist das kein Problem, bei umfangreichen Datenmodellen wird es mühsam.

Direkter Vergleich.

Entscheidungshilfe.

1. Wenige hundert Seiten, einfache Struktur? REST reicht.
2. Viele tausend Seiten? GraphQL, wegen der Bauzeit.
3. Stark verschachtelte Inhalte mit Verknüpfungen? GraphQL.
4. Feld-Plugin im Einsatz? Prüfen, welche Schnittstelle es sauber bedient.
5. Team ohne GraphQL-Erfahrung? REST, der Lernaufwand ist real.
6. Möglichst wenig Abhängigkeiten gewünscht? REST.

Punkt vier entscheidet in der Praxis häufiger als alles andere. Wenn das Feld-Plugin, mit dem die Inhaltsstruktur gebaut ist, nur eine der beiden Schnittstellen gut unterstützt, ist die Entscheidung gefallen.

Beides mischen.

Möglich und manchmal sinnvoll. Typisch: GraphQL für die Inhalte, REST für einzelne Sonderfälle — etwa einen eigenen Endpunkt für das Kontaktformular oder die Vorschau.

Das ist kein Stilbruch, sondern pragmatisch. Wichtig ist nur, dass es eine bewusste Entscheidung bleibt und nicht daraus entsteht, dass niemand mehr weiß, warum welcher Weg genommen wurde (Aufbau in der Praxis).

Wenn du weiterkommen willst.

Wenn du vor dieser Entscheidung stehst und sie nicht in einem Jahr bereuen willst. Ich schaue mir an, was du vorhast, und sage dir, ob headless passt — und wenn nicht, was stattdessen: Headless WordPress. Geht es nur um Tempo, ist oft Ladezeitarbeit an der bestehenden Seite der günstigere Weg.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich arbeite seit Jahren mit WordPress und baue daneben eigene Plattformen mit Next.js — Lernplattformen mit mehreren tausend Seiten, bei denen WordPress als Redaktionssystem im Hintergrund läuft und das Frontend davon getrennt ist. Das ist also keine Theorie, sondern das, womit ich meine eigenen Projekte betreibe.

Genau deshalb sage ich auch offen, wann es sich nicht lohnt. Headless ist aufwendiger im Bau und im Betrieb, und für eine normale Unternehmenswebsite ist es fast immer die falsche Antwort. Wer mir schreibt und eine fünfzehnseitige Firmenwebsite headless bauen lassen will, bekommt von mir eine Rückfrage und keinen Kostenvoranschlag.

Was ich nicht mache: große Teams begleiten oder bestehende Frontends in anderen Frameworks übernehmen. Mein Feld ist WordPress als Redaktionssystem plus ein Frontend in Next.js — überschaubar im Umfang, von einer Person wartbar.