Warum das in Ihrer Woche auftaucht
Ein Headless-Launch ist in zwei Wochen. Die React-App erwartet Custom Fields, die nie in REST-Responses erscheinen. Oder schlimmer: Application Passwords wurden für eine Demo erstellt und nie widerrufen. Die API ist, wo Content-Architektur auf Security trifft.
Klartext
Öffentliche Sites erlauben oft Lesezugriff auf veröffentlichte Inhalte. Erstellen, Aktualisieren und Löschen brauchen authentifizierte User mit passenden Capabilities.
Custom Post Types und Felder brauchen explizite REST-Unterstützung. ACF und ähnliche Tools müssen konfiguriert sein, bevor ein Headless-Frontend darauf bauen kann.
Application Passwords, OAuth-Plugins und JWT-Setups sind Credentials. Behandeln Sie sie wie Production-API-Keys mit Rotation und Least Privilege.
Headless WordPress nutzt die REST API (oder GraphQL-Plugins) als Content-Backend, während ein anderes Frontend HTML rendert.
Deaktivieren oder sperren Sie Routes, die Sie nicht brauchen. Jeder offene Write-Endpoint ist Angriffsfläche.
Fakten zum Behalten
- Base-Pfad
- Typischerweise /wp-json/
- Format
- JSON über HTTP
- Im Core seit
- REST API reifte in WordPress Core (4.7+-Ära für Core-Content-Routes)
- Typische Clients
- Headless-Frontends, Mobile Apps, Zapier-Klasse-Automatisierungen, Custom-Integrationen
- Auth-Optionen
- Cookie-Auth (Admin), Application Passwords, OAuth/JWT via Plugins
Nicht dasselbe wie
- WP-CronEin Job-Scheduler, keine HTTP-Content-API.
- GraphQL für WordPressSeparater Plugin-Ansatz, den manche Headless-Stacks bevorzugen. Anderes Query-Modell, gleiche Auth- und Field-Exposure-Disziplin nötig.
- Die admin-ajax.php-GewohnheitÄltere WordPress-Muster posten zu admin-ajax. REST ist der klarere Vertrag für moderne Integrationen.
Wo es wehtut
Die REST API tut weh, wenn ein Headless-Launch fehlende Felder entdeckt, oder wenn Application Passwords und Plugin-Routes offener bleiben, als das Security-Review annahm.
Content-Freezes und Credential-Cleanups landen dann in derselben Woche wie eine Marketing-Deadline.
Was zu prüfen ist
- Welche Endpoints sind öffentlich, welche brauchen Authentifizierung?
- Erscheinen Custom Fields, die das Frontend braucht, absichtlich in REST-Responses?
- Sind Application Passwords und Plugin-Routes wie jede andere Production-API reviewed?
- Gibt es Rate Limiting oder WAF-Regeln gegen /wp-json/-Missbrauch?
- Wer owned den Vertrag, wenn das Frontend-Team ein neues Feld braucht?
Häufige Fragen
Was ist die WordPress REST API?
Die eingebaute JSON-HTTP-API zum Lesen und Schreiben von WordPress-Daten, typischerweise unter /wp-json/.
Brauchen Sie die REST API für eine normale WordPress-Site?
Viele Classic Sites nutzen sie kaum. Headless-Frontends, Mobile Apps und Automatisierungs-Workflows hängen daran.
Ist /wp-json/ exponieren gefährlich?
Lesezugriff auf öffentlichen Content ist normal. Write-Routes und verbose User-Endpoints brauchen Härtung, Auth und Monitoring.
Was sollten Sie zuerst prüfen?
Öffentliche versus authentifizierte Routes mappen, Custom Fields absichtlich exponiert bestätigen und Credentials wie bei jeder Production-API prüfen.
REST oder Headless CMS stattdessen?
Wenn WordPress-Redaktions-Workflow eine Stärke ist, kann REST/Headless WordPress funktionieren. Wenn das CMS-Modell gegen Ihr Produkt kämpft, purpose-built Headless CMS evaluieren.