REST-APIs direkt aus TYPO3 zu exponieren war lange ein Flickenteppich aus Custom-Middleware, manuell gepflegten Schemata und proprietären Auth-Lösungen. sg_apicore schließt diesen Aufwand: attributbasiertes Routing, automatische OpenAPI-3.0-Generierung und ein konsequentes Token-System machen TYPO3 zu einem vollwertigen API-Backend. Der Request-Lifecycle folgt den TYPO3-eigenen Konventionen , sodass die Extension ohne Middleware-Anpassungen in bestehende Installationen eingebunden werden kann.
Diese Weiterentwicklung des sgalinski-Pakets sg-apicore bringt Kompatibilität mit TYPO3 v14 und ergänzt die Basis um MCP-Tool-Exposition — womit TYPO3-Instanzen als Tool-Provider in KI-Agenten-Umgebungen fungieren können.
Inhaltsverzeichnis
Überblick
Was wurde gemacht
Funktionen im Detail
Installation
Überblick
sg_apicore ist ein REST- und API-Framework für TYPO3, das attributbasiertes Routing (#[ApiRoute]) mit FastRoute, Multi-API/Multi-Version-Support via ApiRegistry und automatische OpenAPI-3.0-Schemata kombiniert. Die Swagger-UI ist unter /api/{id}/v{version}/docs/ui ohne zusätzliche Konfiguration erreichbar. Token-basierte Authentifizierung unterstützt Opaque Bearer, JWT, FE-Session und BE-Session mit Scope-Enforcement — und das alles über ein Backend-Modul, das APIs, Tokens, Endpoints, Rate Limits und Logs zentral verwaltet.
Auto-CRUD macht beliebige TCA-Tabellen über den TYPO3-DataHandler als REST-Ressourcen verfügbar und ist Workspace-aware: Entwürfe und Versionen werden korrekt berücksichtigt. Besonders für KI-Agenten-Szenarien relevant ist die MCP-Tool-Exposition , die TYPO3-APIs direkt als Tools in Model-Context-Protocol-kompatiblen Clients exponiert.
Diese Weiterentwicklung setzt TYPO3 ^14.3 (inkl. cms-workspaces ^14.3) und PHP ^8.3 voraus. TYPO3 v13 wird in der 14.x-Linie bewusst nicht unterstützt. Das sgalinski-Upstream-Repository liegt auf GitLab und ist nicht öffentlich einsehbar; die genaue Abgrenzung proprietärer Anteile ist daher teils unklar.
sg_apicore im TYPO3-Backend: Registrierte APIs, Versionen, Authentifizierungsmodi und Base Paths werden zentral sichtbar, statt nur in Code oder YAML zu existieren.
Was wurde gemacht
Die Weiterentwicklung gegenüber dem sgalinski-Upstream sg-apicore bestand primär in der TYPO3-14-Portierung: Composer-Anforderungen wurden auf ^14.3 angehoben, die CI-Matrix auf TYPO3 14 umgestellt. PHPStan-Fehler bei Resource-Workspace-Overlays und fehlerhafte Auth-Entrypoints wurden korrigiert.
Zusätzlich wurde ein umfangreicher Upstream-Merge integriert, der zahlreiche Konflikte in Router, TcaMapper, Tests und README umfasste. Hinweis mit Zurückhaltung: Da das Upstream-Repo auf sgalinskis GitLab liegt und nicht öffentlich zugänglich ist, lässt sich die exakte Abgrenzung zwischen proprietären und öffentlichen Anteilen nur eingeschränkt nachvollziehen.
Funktionen im Detail
| Funktion | Nutzen |
|---|---|
| #[ApiRoute] Attribut-Routing | Routen direkt in PHP-Attributen definieren — kein XML, kein YAML |
| Multi-API / Multi-Version via ApiRegistry | Mehrere APIs und Versionen in einer Installation betreiben |
| OpenAPI-3.0-Generierung + Swagger UI | Schema automatisch aus Code generiert, sofort unter /docs/ui erreichbar |
| MCP-Tool-Exposition (JSON-RPC / SSE) | TYPO3 als Tool-Provider in KI-Agenten-Umgebungen einsetzen |
| Token-Auth: Opaque Bearer, JWT, FE/BE-Session | Flexible Auth-Strategien mit Scope-Enforcement per Endpoint |
| Auto-CRUD für TCA-Tabellen | Beliebige TYPO3-Tabellen als REST-Ressourcen ohne Custom-Controller |
| Workspace-Awareness | DataHandler-Operationen berücksichtigen Entwürfe und Workspace-Versionen |
| Backend-Modul | Zentrale Verwaltung von APIs, Tokens, Endpoints, Rate Limits und Logs |
Installation
composer config repositories.sg_apicore vcs https://github.com/dirnbauer/sg_apicore.git
composer require sgalinski/sg-apicore:@devHäufige Fragen
Fazit
sg_apicore schließt eine konkrete Lücke im TYPO3-Ökosystem: REST-APIs, OpenAPI-Dokumentation und MCP-Tool-Exposition aus einer einzigen Extension heraus, ohne Middleware-Flickwerk. Die v14-Portierung macht die Extension für aktuelle Projekte einsetzbar. Der Hinweis auf die eingeschränkte Transparenz des Upstreams ist bewusst — wer Klarheit über Lizenz und Herkunft benötigt, sollte das vor dem Einsatz prüfen.
sg_apicore ist ein Fork von sgalinskis sg-apicore. Dank an sgalinski für die Vorarbeit. Die Extension steht unter der GPL-2.0-or-later.