WordPress als Datenquelle: So nutzt ihr die WP-REST-API

(Grafik: Shutterstock)
Eine Webseite mit WordPress zu erstellen, ist keine Besonderheit mehr. Die Idee, WordPress nicht nur als einzelne Webseite zu benutzen, sondern auch als Datenquelle für weitere Produkte, schon. Dafür brauchen wir eigentlich nicht viel: nur eine aktuelle WordPress-Installation und das Plugin „WP REST API“.
Eine REST-API ist kein Abfallprodukt
Eine REST-API (Representational State Transfer Application Programming Interface) ermöglicht den Austausch von Informationen zwischen verschiedenen Systemen, auch Maschine-Maschine-Kommunikation genannt. Über eine REST-API können wir Aufgaben und Informationen auf verschiedenen Servern verteilen und über einen HTTP-Request anfordern. Dieser HTTP-Request besteht aus einem sogenannten Endpoint und den dazugehören Parameter.
Das hört sich schwieriger an, als es ist. Eine solche API haben wir schon oft benutzt, ohne es zu merken. Zum Beispiel bei Platzhalter-Bildern, die über eine URL und die dazugehören Farben, Größen oder Texten generiert werden. Beispiel: http://placehold.it/30×200. Die Domain placehold.it wäre in diesem Fall der Endpoint und /30×200 wären die Parameter.
Natürlich ist das eine sehr vereinfachte Form. Bei diesem HTTP-Response erhalten wird direkt das Bild mit dem richtigen MIME-Type, das wir direkt weiterverarbeiten können. Bei einer komplexen REST-API erhalten wir meist eine XML oder besser einen JSON-Response, den wir weiterverarbeiten müssen. Dabei werden Access-Token übergeben und es gibt eine Vielzahl von Endpoints, Parameter und Methoden.
REST-API und WordPress
Eine solche REST-API kann natürlich dafür sorgen, dass wir aufwendige Aufgaben auf andere Server auslagern können, um die Performance zu stabilisieren. Eine andere Möglichkeit ist, wie auch bei den Placeholder-Images, schon vorhandene Services zu benutzen. Bei unserer Zusammenführung von WordPress und einer REST-API geht es aber um die Möglichkeit, schon vorhande Informationen und Datenquellen in ein anderes Produkt einfließen zu lassen. Das hat den Vorteil, dass wir nur noch eine Datenquelle pflegen müssen und die Inhalte automatisch in allen anderen Produkten zur Verfügung stehen.
Ein Beispiel für ein solches Produkt wäre eine App für iOS oder Android, über die die gleichen Inhalte automatisch direkt auf das Smartphone oder Tablet verteilt werden. Wir könnten mit einer solchen API auch unser eigenes Dashboard bauen, das als native Applikation auf dem Rechner läuft. Den Ideen sind keine Grenzen gesetzt.
WP REST API: Vorbereitung

WordPress WP REST API Plugin (Grafik: wordpress.org)
Bevor wir starten können, müssen wir das Plugin „WP REST API“ auf unserer WordPress-Seite installieren. Wer eine ausführliche Dokumentation des Plugins sucht, findet sie auf der offiziellen Webseite. Sobald wir das Plugin installiert haben, können wir auch direkt loslegen. Um zu überprüfen, ob die REST-API funktioniert, könnt ihr folgende URL in eurem Browser aufrufen:
http://domain.tld/wp-json
Unter diesem Endpoint solltet ihr die Basis-Informationen eurer WordPress-Installation erhalten (HTTP/1.1 200 OK).
WP REST API: HEAD, GET, POST, PUT, PATCH, DELETE
Um jetzt das konkrete Beispiel einer eigenen App aufzugreifen, überlegen wir uns erst mal ihre Funktionalität. Zuerst sollen die letzten zehn Artikel aufgeführt werden, es soll eine zusätzliche Suche geben und wir wollen gerne unser Logo aus der Mediathek auslesen.
10 Artikel:
http://domain.tld/wp-json/posts?filter[posts_per_page]=10
Beitrags-Suche:
http://domain.tld/wp-json/posts?filter[s]=hallo
Bild mit ID:
http://domain.tld/wp-json/media?filter[attachment_id]=1
Alle weiteren Funktionen und Möglichkeiten können aus der Dokumentation entnommen werden. Zu Testzwecken können wir den HTTP-Request direkt in unserem Browser aufrufen. Später wird dieser Aufruf natürlich im Programmcode der jeweiligen Anwendung hinterlegt. Beispielsweise könnte man einen solchen Request mit jQuery Ajax abfeuern. Daraufhin würde die Funktion den HTTP-Response erhalten, der in ein JavaScript-Objekt umgewandelt und ausgelesen wird. Mit diesen Möglichkeiten können wir einfach und schnell auf die Inhalte zugreifen und WordPress als Datenquelle benutzen.
Wichtig: Natürlich sind nicht alle Funktionen public. Das Anlegen von neuen Benutzern oder Beiträgen zum Beispiel darf natürlich nicht für jeden möglich sein, der die API benutzt. Daten anlegen, bearbeiten und löschen benötigt meist eine Authentifizierung. Es gibt insgesamt drei Wege, die Berechtigung für solche Anfragen zu erteilen. Diese könnt ihr auf der folgenden offiziellen Seite nachlesen. Wer dagegen nur Daten auslesen will, die schon öffentlich sind, benötigt eine solche Authentifizierung nicht. Ob ihr sie braucht oder nicht, steht jeweils unterhalb der Funktion in der Dokumentation.
Welche Ideen habt ihr für die Nutzung einer REST-API?
Sorry, aber dass die Domain der Endpoint wäre ist ja mal kompletter Bullshit. Endpoints sind die einzelnen Endpunkte (wer hätte es gedacht :D) auf die zugegriffen werden kann, also zum Beispiel domain.tld/task/3
„task“ ist der Endpoint und „3“ ein Parameter. Immer dieses halbgare Wissen hier. Ich könnte kotzen.
Es ist zwar Samstag, ich habe shon 4 Bier intus, aber: In diesem Beispiel ist die Domain der Endpoint. Ich kotze, da zu viel Bier.
Hallo DerNivel und Suisse,
vielen Dank für eure Kommentare und der Anteilnahme eurer Ausscheidungen. In diesem vereinfachten Beispiel ging es darum, Neulingen das Grundverständnis einer API näher zu bringen. Bedingt durch ein einfaches Beispiel, gibt es keinen typischen Endpoint. Trotzdem hat die Domain, in diesem Beispiel, die gleiche Funktionsweise wie normalerweise ein Endpoint bzw. der / – bei weiteren Unklarheiten kann ich dieses aber gerne nochmals verdeutlichen, damit der Artikel auch weiterhin bei „4 Bier intus“ leserlich bleibt. Ich danke euch, für euer Feedback!
Leider vermittelt der Artikel Neulingen aber etwas total falsches und zwar, dass die Domain der Endpoint sei, was in diesem Fall jetzt zutrifft, aber wohl meistens nicht der Fall ist. Gerade, wenn du Neulingen das Grundverständnis einer API näher bringen möchtest, muss man klar machen, dass die Domain nicht gleich Endpoint ist, sondern nur in diesem speziellen Fall!
Das ging schon mit Perl und Pipes als Trenner. Hat weniger Overhead