Knowledge
Ein React-Frontend braucht Daten aus TYPO3, eine App lädt ihren Katalog, ein Partner möchte die Termine in seinen Kalender übernehmen. Und umgekehrt sollen Daten aus einem Fremdsystem auf der Website erscheinen. Für beide Richtungen bringt TYPO3 die Bausteine mit, eine fertige REST-API für alle Inhalte allerdings nicht.
REST ist eine verbreitete Art, Schnittstellen im Web zu bauen. Jede Ressource, etwa ein Termin oder ein Produkt, hat eine eigene Adresse, und eine Anwendung ruft sie per HTTP ab oder ändert sie. Die Antwort kommt in der Regel als JSON.
Eine allgemeine REST-API für Seiten und Datensätze gehört nicht zum TYPO3-Core. Der Core liefert die Bausteine, aus denen eine Schnittstelle entsteht: das Routing, die Middleware-Kette nach dem Standard PSR-15, Extbase, die Benutzerverwaltung und das Caching-Framework. Darauf bauen eigene Extensions ebenso auf wie solche aus der Community. Welcher Weg passt, hängt davon ab, welche Daten gebraucht werden und wer sie abruft.
Daten bereitstellen
Für eigene Datenmodelle wie Termine, Produkte oder Aufgaben ist eine Schnittstelle in einer eigenen Extension oft der direkteste Weg. Solche Extensions sind ein Schwerpunkt meiner TYPO3-Entwicklung. Eine solche Schnittstelle liefert genau die Felder, die die Anwendung braucht, in der Struktur, die sie erwartet. Technisch gibt es zwei Varianten.
Ein Extbase-Controller kann statt eines Fluid-Templates JSON zurückgeben,
über die JsonView oder die Methode jsonResponse().
Der Endpunkt läuft dann als Plugin auf einem eigenen Seitentyp. Das bringt
den Komfort von Extbase mit: Argumente werden auf Objekte abgebildet und
validiert, die Konfiguration kommt aus TypoScript, und die Antwort kann den
Seiten-Cache von TYPO3 nutzen. Dafür durchläuft jeder Aufruf das
Frontend-Rendering.
Schlanker ist eine PSR-15-Middleware. Sie sitzt in der Kette, die jede Anfrage durchläuft, erkennt ihre Adresse und antwortet direkt, bevor TYPO3 eine Seite rendert. Das ist schnell und gut kontrollierbar, Caching und Validierung liegen dann aber in der eigenen Hand. Extbase gehört nicht in eine Middleware: Seit TYPO3 v14 rät die Dokumentation ausdrücklich davon ab, weil Extbase auf das Frontend-TypoScript angewiesen ist.
Im Kern ist eine solche Middleware überschaubar. Die Registrierung ordnet sie hinter der Erkennung der Site ein:
return [
'frontend' => [
'vendor/termine-api' => [
'target' => \Vendor\Termine\Middleware\TermineApi::class,
'after' => ['typo3/cms-frontend/site'],
],
],
];Die Middleware selbst prüft den Pfad und gibt entweder JSON zurück oder reicht die Anfrage unverändert weiter:
public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
if ($request->getUri()->getPath() !== '/api/v1/termine') {
return $handler->handle($request);
}
return new JsonResponse($this->termine->upcoming());
}Beim Mixometer stellt eine eigene JSON-Schnittstelle den Produktkatalog aus TYPO3 für eine App bereit. Über dieselbe Schnittstelle laufen auch Anmeldung und Synchronisation. Für ein Planungstool einer Agentur liefert TYPO3 Mitarbeitende, Kunden, Jobs und Feiertage per REST an eine React-Anwendung, die Filter und Ansichten direkt im Browser verarbeitet.
Soll ein JavaScript-Frontend die Inhalte der ganzen Website darstellen, also
Seitenbaum, Navigation und Inhaltselemente, ist die Extension
headless der naheliegende Weg. Sie entsteht im Rahmen der
TYPO3-PWA-Initiative, wird über das Composer-Paket
friendsoftypo3/headless installiert und gibt Seiten,
Inhaltselemente, Navigation und Metadaten als JSON aus. Formulare aus dem
Form-Framework und der Frontend-Login sind ebenfalls abgedeckt. Als Gegenstück
gibt es nuxt-typo3, ein Frontend auf Basis von Vue und Nuxt, das
diese Ausgabe direkt verarbeitet.
Für TYPO3 v14 ist die Version 5 zuständig, die im September 2026 als Release Candidate erschienen ist. Die Versionen 4.x für TYPO3 v12 und v13 erhalten weiterhin Fehler- und Sicherheitskorrekturen.
Was es bedeutet, eine Website so zu betreiben, und wann sich das lohnt, beschreibe ich im Artikel Headless CMS.
Die Extension t3api (Composer-Paket
sourcebroker/t3api) verfolgt einen anderen Ansatz. Sie baut auf
API Platform auf: Extbase-Modelle werden per Annotation zu Ressourcen der API,
Filter, Paginierung und Bildverarbeitung sind eingebaut, und die Antworten
kommen im Format Hydra/JSON-LD. Das spart Arbeit, wenn viele Datenmodelle mit
ähnlichen Anforderungen angebunden werden.
Die aktuelle Version 4.1 unterstützt TYPO3 v12.4 und v13. Eine Version für TYPO3 v14 ist bisher nicht veröffentlicht (Stand Oktober 2026). Wer ein neues Projekt auf TYPO3 v14 plant, sollte das vor der Entscheidung klären.
Ein öffentlicher Spielplan darf ruhig frei abrufbar sein. Sobald eine Schnittstelle personenbezogene Daten ausgibt oder Daten schreibt, gehört eine Anmeldung dazu.
Läuft die Anwendung im Browser unter derselben Domain wie TYPO3, kann sie die vorhandene Anmeldung mitbenutzen: Die Schnittstelle prüft die Sitzung und die Benutzergruppen, die TYPO3 ohnehin verwaltet. Beim Planungstool laufen Anmeldung, Rollen und Berechtigungen über TYPO3. Die Anwendung kommt dadurch ohne eigene Benutzerverwaltung aus.
Apps und Verbindungen zwischen Servern arbeiten mit Tokens. Die App meldet sich einmal an und schickt danach bei jeder Anfrage einen Token mit, ein Partnersystem bekommt einen eigenen Schlüssel mit genau den Rechten, die es braucht. Abgesichert wird das über HTTPS, Tokens mit begrenzter Laufzeit und die Möglichkeit, einen einzelnen Schlüssel zu sperren. Schreibende Zugriffe prüft die Schnittstelle so sorgfältig wie ein Formular: Jeder Wert wird validiert, bevor er in der Datenbank landet.
Eine Schnittstelle wird oft häufiger abgerufen als die Website selbst, etwa wenn jede App beim Start den Katalog prüft. Gutes Caching hält die Antwortzeiten auch dann kurz.
Läuft der Endpunkt über Extbase und einen eigenen Seitentyp, cacht TYPO3 die Antwort wie eine Seite. Bei einer Middleware übernimmt das Caching-Framework von TYPO3 diese Aufgabe. Die Einträge bekommen Tags, etwa für den Spielplan oder eine Produktkategorie, und werden gezielt geleert, sobald die Redaktion einen passenden Datensatz ändert.
Dazu kommen HTTP-Header wie Cache-Control und ETag.
Mit ihnen erkennen Browser, Apps und vorgelagerte Caches selbst, ob sich etwas
geändert hat. Bei großen Datenmengen hilft ein Abgleich nach Änderungsdatum:
Die Mixometer-App überträgt bei der Synchronisation nur die Daten seit dem
letzten Abgleich.
Eine Schnittstelle ist eine Zusage an alle Anwendungen, die sie nutzen. Bei
Apps gilt das besonders, denn ältere Versionen bleiben oft noch lange auf den
Smartphones installiert. Deshalb gehört die Version von Anfang an in die
Adresse, zum Beispiel /api/v1/termine.
Neue Felder lassen sich jederzeit ergänzen, bestehende Anwendungen arbeiten unverändert weiter. Ändert sich die Struktur grundlegend, entsteht eine v2, und v1 läuft parallel, bis alle Anwendungen umgestellt sind. Eine Beschreibung im Format OpenAPI hält fest, was die Schnittstelle liefert, und dient dem Frontend-Team als Referenz.
Daten abrufen
In der anderen Richtung werden Termine, Produkte oder Stellenangebote in einem Fremdsystem gepflegt und sollen auf der Website erscheinen. Dafür gibt es zwei Grundmuster: den Import und die Live-Abfrage.
Beim Import holt TYPO3 die Daten regelmäßig ab und legt sie als Datensätze an. Dahinter steckt ein Konsolenbefehl auf Basis von Symfony Console, den der Scheduler von TYPO3 oder ein Cronjob in festen Abständen startet. Bei Bedarf lässt er sich auch von Hand aufrufen.
Die Website arbeitet dann mit lokalen Daten. Seiten laden schnell, die Daten lassen sich durchsuchen, filtern und von der Redaktion ergänzen, und die Website zeigt ihren Stand auch dann, wenn das Fremdsystem gerade nicht erreichbar ist.
So arbeitet die Anbindung eines Theaters an Theasoft: Eine eigene Extension ruft regelmäßig den vollständigen Spielplan ab und gleicht ihn mit dem Bestand ab. Die Redaktion ergänzt in TYPO3 Texte, Bilder und Videos, und die Volltextsuche findet auch Besetzungen. Hier kommen beide Richtungen zusammen: Die importierten Daten stellt TYPO3 anschließend selbst per API für externe Terminkalender bereit.
Ein Import muss nicht über eine Schnittstelle laufen. Beim Mixometer stellen Hersteller ihre Produktlisten zum Beispiel als Excel-Datei bereit, die über ein Backend-Modul in TYPO3 importiert wird.
Bei der Live-Abfrage fragt TYPO3 das Fremdsystem erst in dem Moment, in dem
jemand die Seite aufruft. Der Core bringt dafür mit der
RequestFactory einen HTTP-Client auf Basis von Guzzle mit. Das
passt zu Daten, die sich ständig ändern und nur an einer Stelle gebraucht
werden, wie eine Verfügbarkeit oder ein Status.
Dafür hängt die Seite an der Antwortzeit des anderen Systems. Deshalb braucht es kurze Timeouts, eine Antwort, die für einige Minuten im Cache bleibt, und eine Ausgabe für den Fall, dass das Fremdsystem nicht antwortet. Für die Suche, für Filter und für Inhalte, die Suchmaschinen finden sollen, ist der Import die bessere Wahl.
Statt in festen Abständen nachzufragen, kann das Fremdsystem TYPO3 auch selbst über Änderungen informieren. Seit TYPO3 v12 nimmt die Systemextension Reactions solche eingehenden Webhooks entgegen. Jede Reaktion hat eine eigene Adresse und ein Secret, beides wird im Backend erzeugt. Mitgeliefert ist eine Reaktion, die aus den gesendeten Daten einen Datensatz anlegt. Eine selbst geschriebene Reaktion kann auch einen Import anstoßen, sobald sich im Quellsystem etwas ändert.
Die Gegenrichtung deckt die Systemextension Webhooks ab. TYPO3 meldet damit etwa geänderte Seiten oder neue Dateien an eine Adresse und signiert jede Nachricht, sodass der Empfänger die Herkunft prüfen kann.
Eine Anbindung läuft über Jahre. In dieser Zeit liefert jedes Fremdsystem irgendwann unvollständige Daten, ändert ein Feld oder ist für eine Nacht nicht erreichbar. Eine gute Anbindung rechnet damit:
FAQ
Eine allgemeine REST-API für Seiten und Datensätze gehört nicht zum TYPO3-Core. Der Core bringt die Bausteine mit: Routing, Middlewares nach PSR-15, Extbase mit JSON-Ausgabe, die Benutzerverwaltung und das Caching-Framework. Darauf setzen eigene Endpunkte in einer Extension oder Extensions wie headless und t3api auf.
Für die Inhalte einer ganzen Website, also Seiten, Navigation und Inhaltselemente, passt die Extension headless. Für viele Extbase-Datenmodelle mit Filtern und Paginierung bietet sich t3api an, das (Stand Oktober 2026) TYPO3 v12.4 und v13 unterstützt. Wenn eine Anwendung genau bestimmte Daten in einer festen Struktur braucht, ist ein eigener Endpunkt in einer Extension oft der direkteste Weg.
Meist per Import: Ein Konsolenbefehl, den der Scheduler startet, holt die Daten in festen Abständen ab und legt sie als Datensätze in TYPO3 an. Für Daten, die sich ständig ändern, fragt TYPO3 das Fremdsystem live beim Seitenaufruf ab und cacht die Antwort kurz. Meldet das Fremdsystem Änderungen selbst, nimmt die Systemextension Reactions diese Webhooks entgegen.
Weiterlesen oder direkt ins Gespräch: