Share
Mit seiner Gründung im Jahr 2003 hat sich WordPress von einer bloßen Blogging-Plattform zu einem vollwertigen Content-Management-System entwickelt. In den letzten Jahren ist es so weit gereift, dass die große Mehrheit der Online-Besucher auf dieses Bedürfnis eingehen kann. Dies ist der Grund, warum es heute mehr als 20% des Internets unterstützt.
Mit vielen neuen Funktionen, die in WordPress hinzugefügt werden, ist eine der neuesten Erweiterungen die REST-API, mit der andere Apps und Plattformen mit WordPress interagieren können. Es ist eine revolutionäre Ergänzung, die Entwicklern dabei hilft, mit WordPress benutzerdefinierte Anwendungen und integrierte Systeme zu erstellen. Da es die Möglichkeit bietet, Inhalte von anderen Clients oder Sites hinzuzufügen und abzurufen, ohne dass WordPress auf dieser Site installiert werden muss, kann WordPress mit jeder Programmiersprache oder -plattform verwendet werden.
In dieser mehrteiligen Serie werfen wir einen Blick auf die WP REST-API und wie sie verwendet werden könnte, um Benutzererfahrungen zu erstellen, die ansonsten mit WordPress nicht möglich oder zumindest mühsam sind. Wir werden zunächst einen Blick auf grundlegende Konzepte wie REST und JSON werfen und dann über die WP REST-API die verfügbaren Optionen untersuchen.
Nachfolgend finden Sie einige Ressourcen, die ich für grundlegende Konzepte wie HTTP, REST und JSON als nützlich empfunden habe. Ich empfehle Ihnen dringend, sich diese anzuschauen, wenn Sie noch nicht
Bevor wir mit unserem Thema beginnen, werfen wir einen kurzen Blick auf die REST-Architektur und machen uns mit ihrer gängigen Terminologie vertraut.
Um mit dem Thema zu beginnen, werfen wir einen Blick auf REST (Repräsentation State TArchitektur und einige ihrer gebräuchlichsten Konzepte. Sie zu verstehen, ist wichtig, wenn Sie Anwendungen mit dem REST-Architekturstil entwickeln.
REST ist ein Architekturstil, mit dessen Hilfe ein verteiltes System erstellt und organisiert werden kann. Es beschreibt das Web als verteilte Hypermedia-Anwendung, deren verknüpfte Ressourcen durch den Austausch von Repräsentationen von kommunizieren Ressource Zustand.
Ressourcen sind die Hauptbausteine der REST-Architektur. Tatsächlich sind sie die Hauptbausteine des Webs selbst, sofern das Web manchmal als "ressourcenorientiert" bezeichnet wird..
Bei WordPress handelt es sich bei diesen Ressourcen um diskrete Entitäten wie Beiträge, Seiten, Kommentare, Benutzer und benutzerdefinierte Beitragstypen usw., um mit Ressourcen zu interagieren, URIs (Uniform Resource Identifier) werden verwendet, und wie der Name vermuten lässt, handelt es sich um einen Bezeichner für eine Ressource.
Ein RESTful-Dienst behandelt URIs als primäre Methode zum Adressieren einer zugrunde liegenden Ressource. Diese Ressource kann mehrere haben Darstellungen. Beispielsweise kann eine Bilddatei in den Formaten .JPG, .GIF oder .PNG verfügbar sein. Die Beziehung zwischen Ressourcen und URIs ist Eins-zu-Viele. Ein URI kann nur auf eine bestimmte Ressource verweisen, eine Ressource kann jedoch mehr als einen URI haben.
Die Liste aller derzeit von der WP-REST-API unterstützten Ressourcen ist wie folgt:
Wir können verschiedene Aktionen für diese Ressourcen mithilfe von HTTP-Verben ausführen.
Eine REST-API ermöglicht grundsätzlich die Durchführung von CRUD-Vorgängen (Create Read Update Delete) für Ressourcen über HTTP. Zu diesem Zweck verwendet REST einen begrenzten Satz von HTTP-Anforderungsverben, die wie folgt lauten:
Accentsconagua
ERHALTEN: Zum Lesen oder Abrufen einer RessourcePOST: Zum Erstellen einer neuen RessourceSTELLEN: Wird zum Aktualisieren einer Ressource verwendetLÖSCHEN: Zum Löschen einer RessourceKOPF: Wird verwendet, um zu überprüfen, ob eine Ressource vorhanden ist, ohne ihre Darstellung zurückzugebenOPTIONEN: Zum Abrufen aller von einer Ressource unterstützten VerbenIn einem RESTful-Service haben diese Verben eine klar definierte Bedeutung. Die ersten vier Verben in der obigen Liste sind Teil von CRUD-Aktionen, d. H. Sie rufen Entitäten ab, erstellen, aktualisieren und löschen sie. Die letzten beiden Verben helfen einem Client bei der Bestimmung, ob eine Ressource vorhanden ist und welche HTTP-Verben für die Ausführung weiterer Vorgänge verfügbar sind.
EIN ERHALTEN request ruft Informationen ab und ist idempotent, d. h. ein Client kann sie mehrmals aufrufen, hat jedoch keinen Einfluss auf den Status einer Ressource.
Um alle Beiträge mithilfe der WP-REST-API abzurufen, verwenden wir Folgendes Endpunkt:
GET wp / v2 / Beiträge
Der obige Endpunkt gibt a zurück Sammlung von allen Postentitäten.
Wenn der folgende Endpunkt ausgelöst wird, wird ein bestimmter zurückgegeben Entität ein Post mit einer ID von 100:
GET wp / v2 / posts / 100
EIN POST request erstellt eine neue Entität und a STELLEN Anfrage ersetzt diese Entität durch eine neue Version.
Folgende POST request kann verwendet werden, um einen neuen Beitrag zu erstellen (das Senden des Anfragetextes, den wir im späteren Teil der Serie betrachten werden) mithilfe der WP REST-API:
POST wp / v2 / posts
Und die folgende STELLEN request aktualisiert einen Beitrag mit der ID 100:
PUT wp / v2 / posts / 100
EIN LÖSCHEN Anfrage löscht eine Ressource aus dem System. Diese Art von Anfrage zusammen mit STELLEN request sind wiederholbar, was bedeutet, dass der Aufruf dieser Methoden die gleiche Wirkung auf das System hat. Zum Beispiel, wenn Sie a anrufen STELLEN Wenn Sie eine Ressource mehrmals anfordern (mit den gleichen Argumenten), wird das Ergebnis dasselbe sein. Das gleiche gilt für eine LÖSCHEN anfordern. Das mehrfache Löschen einer Ressource hat die gleiche Wirkung, d. H. Die Ressource wird gelöscht (oder bei einer bereits gelöschten Ressource wird ein Fehler zurückgegeben)..
Zusätzlich zu diesen CRUD-Aktionen stellt ein RESTful-Dienst zwei weitere Verben zur Verfügung OPTIONEN und KOPF. Diese Verben sind nützlich, wenn ein Client prüfen muss, welche Ressourcen im System verfügbar sind und welche Aktionen er unterstützt. Auf diese Weise kann der Client das System genauer untersuchen und Aktionen ausführen. Wir werden diese beiden Methoden später in diesem Tutorial in Aktion sehen.
Beachten Sie, dass wir im ersten Beispiel das Folgende verwendet haben Endpunkt:
GET wp / v2 / Beiträge
Endpunkte sind Funktionen, die über die API verfügbar sind. Sie führen verschiedene Aktionen aus, z. B. das Abrufen von Posts (die wir oben ausführen), das Erstellen eines neuen Benutzers oder das Aktualisieren eines Post-Metas. Alternativ können wir sagen, dass ein Endpunkt eine Methode auslöst, die eine bestimmte Aufgabe ausführt. Diese Endpunkte hängen von dem ihnen zugeordneten HTTP-Verb ab. Im obigen Beispiel verwenden wir das Verb GET, um alle Beiträge abzurufen.
Das Route Für den obigen Endpunkt gilt Folgendes:
WP / V2 / Beiträge
Eine Route ist im Wesentlichen ein Name, um auf den Endpunkt zuzugreifen. Eine Route kann mehrere Endpunkte haben, die auf HTTP-Verben basieren. Die obige Route hat also den folgenden Endpunkt, um einen neuen Beitrag zu erstellen:
POST wp / v2 / posts
Wenn dieser Endpunkt mit den angegebenen Parametern ausgelöst wird, wird eine neue Nachentität erstellt.
Betrachten Sie die folgende Route:
wp / v2 / posts / 100
Diese Route zeigt auf die Entität Post mit der ID 100. Sie hat die folgenden drei Endpunkte:
GET wp / v2 / posts / 100: Mit dieser Option kann der Beitrag mit der ID 100 abgerufen werden get_item () Methode.PUT wp / v2 / posts / 100: Kann verwendet werden, um den Beitrag mit der ID 100 zu aktualisieren. Er löst das aus update_item () Methode.LÖSCHEN Sie wp / v2 / posts / 100: Löscht den Beitrag mit der ID 100. Er löst den Post aus Element löschen() Methode.Im letzten Teil dieser Serie erfahren Sie mehr über die Internen der WP REST-API, ihre Klassenstruktur und ihre internen Methoden.
Lassen Sie uns nun unser Wissen über einige allgemeine HTTP-Antwortcodes und deren Bedeutung auffrischen.
Ein Server antwortet auf eine Anforderung, indem er eine Antwort zurücksendet, die einen HTTP-Statuscode enthält. Diese Codes sind Zahlen mit vordefinierten Bedeutungen. Jeder, der das Internet nutzt, ist beispielsweise mit dem Internet vertraut 404 Statuscode, der zusammenfasst, dass die Ressource, nach der der Benutzer gesucht hat, nicht gefunden wurde.
Die Antwort des Servers hängt auch von der Art des HTTP-Verbs oder der Methode ab, die in der gesendeten Anforderung verwendet wird.
Nachfolgend finden Sie einige allgemeine HTTP-Antwortcodes sowie deren Bedeutung, auf die wir beim Arbeiten mit der WP REST-API und deren Bedeutung stoßen werden:
200 - OK: Bedeutet, dass die Anforderung erfolgreich abgeschlossen wurde und der Server die Antwort zurückgegeben hat. In der Regel nach einem erfolgreichen zurückgegeben ERHALTEN anfordern.201 - erstellt: Wird in der Regel nach einem erfolgreichen Erfolg zurückgegeben POST anfordern. Fasst zusammen, dass die Ressource erstellt wurde.400 - Schlechte Anfrage: Es wird vom Server zurückgegeben, wenn eine Anforderung mit fehlenden oder ungültigen Parametern gesendet wurde. Wird normalerweise als Antwort auf zurückgegeben POST oder STELLEN Anfragen.401 nicht Autorisiert: Bedeutet, dass der Benutzer nicht berechtigt ist, bestimmte Aktionen auszuführen. Beispielsweise hat ein Benutzer versucht, eine Ressource zu erstellen oder zu löschen, ohne Authentifizierungsinformationen anzugeben.403 Verboten: Bedeutet, dass der Server die Anfrage verstanden hat, sie aber aufgrund der Authentifizierung nicht abschließen konnte. Dies geschieht, wenn ein Benutzer Authentifizierungsdaten angibt, jedoch nicht über die erforderlichen Rechte zum Ausführen der Aktion verfügt.404 Nicht gefunden: Der (in) berühmteste aller Statuscodes. Fasst zusammen, dass eine Ressource, nach der der Benutzer gesucht hat, nicht gefunden wurde.405 - Methode nicht zulässig: Bedeutet, dass ein in der Anforderung angegebenes HTTP-Verb von der Ressource nicht unterstützt wurde. Ein Beispiel könnte ein Benutzer sein, der versucht, eine schreibgeschützte Ressource zu aktualisieren.410 - weg: Bedeutet, dass eine Ressource an einen anderen Ort verschoben wurde. Ein Beispiel ist der Versuch, eine bereits gelöschte Ressource zu löschen, die in den Papierkorb verschoben wurde.500 - Interner Serverfehler: Wird zurückgegeben, wenn ein Server auf einen unerwarteten Zustand trifft und die Anforderung nicht abschließt.501 - Nicht implementiert: Bedeutet, dass der Server die Funktionalität zum Abschließen der Anforderung nicht unterstützt. Tritt normalerweise auf, wenn ein Server eine Anforderungsmethode empfängt, die er nicht erkennt.Wir werden diese HTTP-Verben und Antwortcodes genauer untersuchen, wenn wir tatsächlich mit der API arbeiten. Zuvor werfen wir einen Blick auf die Gründe für die Verwendung der REST-API mit WordPress und die Vorteile, die sie sowohl für den Entwickler als auch für den Benutzer bietet. Schließlich brauche ich ein echtes Interesse daran, mich in dieser Serie mitzuverfolgen.
REST und JSON bieten zusammen einen Mechanismus zum Erstellen leistungsfähiger Anwendungen mit dem WordPress-Backend. Die wichtigsten Beispiele sind mobile Apps, die den Datenaustausch zwischen dem Client (dem Gerät) und dem Server erfordern. Um die Bandbreitenbeschränkungen bei der Verwendung von Mobilfunkdaten im Blick zu behalten, bietet JSON eine Alternative zu XML-basierten Lösungen.
Da JSON ein textbasiertes Format zum Speichern von Daten ist, kann es nahtlos mit den meisten Programmiersprachen verwendet werden. Daher dient JSON als globaler Konnektor beim Datenaustausch zwischen verschiedenen Plattformen, der von Maschinen und Menschen gleichermaßen lesbar ist.
Durch die Verwendung einer API wie der besprochenen ist der Inhalt Ihrer WordPress-Site nicht nur auf sich selbst beschränkt, sondern kann auch von anderen Sites und Clients aufgerufen werden. Da die API einige Teile der internen Funktionalität verfügbar macht, können Remoteclients mit Ihrer Site interagieren, um zu aktualisieren oder neuen Inhalt zu erstellen. Außerdem können einige Inhalte von einer vorhandenen WordPress-Site abgerufen und auf einer anderen Site angezeigt werden.
Mit dem Aufkommen clientseitiger JavaScript-Frameworks wie Angular, Backbone oder Ember ist es jetzt möglich geworden, eines davon zu verwenden, um reichhaltige Benutzererlebnisse zu schaffen, während das WordPress-Backend verwendet wird.
Einige mögliche Anwendungsfälle für die WP REST-API sind:
Es eröffnet wirklich eine neue Welt der Möglichkeiten, in der die Vorstellungskraft die einzige Grenze ist.
Vor JSON-basierten REST-APIs war die API, die zur Remote-Interaktion mit WordPress verwendet wurde, eine XML-RPC-API, die immer noch Teil des WordPress-Kerns ist. Das Problem bei XML ist, dass es nicht so leicht ist wie das JSON-Format und seine Analyse nicht effizient ist. Das Durchqueren von XML ist auch eine große Kopfschmerzen, während das Durchlaufen eines JSON-Objekts genauso einfach ist wie die Verarbeitung eines nativen JavaScript-Objekts.
Das erste REST-API-Plugin, das für WordPress eingeführt wurde, war JSON-API das wurde 2009 veröffentlicht. Es wurde im Museum of Modern Art für seinen Blog Inside / Out gebaut. Das Frontend dieses Blogs wurde von Ruby on Rails angetrieben. Um also Beiträge aus dem WordPress-Backend abzurufen und Kommentare hinzuzufügen, wurde eine API entwickelt. Dieses Plugin bietet Schnittstellen zum Abrufen von Inhalten und Senden von Kommentaren an das WP-Backend. Obwohl dieses Plugin seit mehr als zwei Jahren nicht aktualisiert wurde, ist es immer noch im offiziellen Repository vorhanden und kann abgerufen werden.
Neben dem JSON-API-Plugin bietet WordPress.com bereits eine JSON-API über das JetPack-Plugin an.
Die WP-REST-API, wie wir sie heute kennen, ist ein Feature-Plugin, das von Ryan McCue als Teil von GsoC (Google Summer of Code) 2013 vorgeschlagen wurde. Es ist noch nicht vollständig in den WordPress-Kern einer zukünftigen Version aufgenommen worden. Die aktuelle Version 2.0 des Plugins befindet sich im Betastatus und ist in Version 4.4 teilweise im WordPress-Kern enthalten. Es ist ein Gemeinschaftsprojekt, das von Ryan McCue und Rachel Baker geleitet wird. Die offizielle Repository-Seite des Plugins befindet sich auf GitHub und die offizielle Dokumentation befindet sich auf der Website.
Wie bereits erwähnt, befindet sich die WP REST API derzeit im Plugin-Status und wird derzeit aktiv auf GitHub entwickelt. Es wurde teilweise in den WordPress-Kern in Version 4.4 aufgenommen, und Ryan hat den Plan in seinem Zusammenführungsvorschlag auf WordPress.org beschrieben.
Gemäß dem Zusammenführungsvorschlag würde die WP-REST-API in zwei Schritten in den WP-Kern integriert, wie nachstehend beschrieben:
Dem Vorschlag zufolge wird zu Beginn nur der Code der Infrastrukturebene in Version 4.4 mit dem WP-Kern zusammengeführt. Dieser Infrastrukturcode ist die eigentliche Basis der WP-REST-API, da er JSON-Serialisierung / Deserialisierung, Verknüpfung, Einbettung und die wichtigste von allen enthält - die Routing-Schicht, die die API steuert. Dieser Code enthält keine Endpunkte und deren Controller-Klassen, sie bietet jedoch eine Basis zum Erstellen von APIs in WordPress.
Zum Zeitpunkt des Schreibens wurde dieser Status abgeschlossen und der Infrastrukturcode wurde in Version 4.4 in den WordPress-Kern integriert.
Die Endpunkte für Posts, Seiten, Benutzer und Taxonomien usw. werden in Version 4.5 in den WP-Kern integriert, d. H. Eine Version später als die Zusammenführung des Infrastrukturcodes. Die Endpunkte machen die API für allgemeine Clients nützlich. Sie umfassen viel Komplexität, einschließlich der Zuordnung externer Daten im JSON-Format zu nativen WordPress-Datentypen und umgekehrt. Sie machen den Zweidrittelcode der API selbst mit ungefähr 5500 Zeilen aus.
Die Strategie hier besteht darin, das Vertrauen der Entwickler in die API aufzubauen, indem zunächst der Infrastrukturcode im Kern bereitgestellt wird. Dies würde es Design- und Plugin-Entwicklern ermöglichen, benutzerdefinierte APIs zu erstellen, die in ihre Designs und Plugins aufgenommen werden können. Da Endpoints zu diesem Zeitpunkt jedoch nicht enthalten sind, würde dies den Nutzen der API anfangs einschränken.
Die Lücke zwischen den beiden Releases würde dem WP Core Committer-Team genügend Zeit geben, die API-Endpunkte zu überprüfen.
Ein weiterer Vorteil, den die WP REST-API für die WordPress-Community bringen würde, ist die Verwendung von GitHub in einer Version, die das Projekt steuert. Da alle Beiträge zu WordPress über SVN und Trac geleistet werden, ist das WP REST API-Team sehr zuversichtlich, den Beitragsprozess zu verbessern, indem die Lücke zwischen Trac und GitHub geschlossen wird.
Nach dem Zusammenführen der API in den Kern können wir hoffen, dass in anderen Bereichen, einschließlich der OAuth 1.0a-Authentifizierung, schnelle Entwicklungen zu verzeichnen sind.
Um mit der WP-REST-API zu testen, benötigen wir einen HTTP-Client, der zum Senden von Anforderungen an den Server und zum Anzeigen der Antwort verwendet wird. Es ist wirklich eine Frage Ihrer Wahl, aber ich werde in dieser Serie Postman für Google Chrome verwenden. Andere Alternativen zu Postman sind:
Postman ermöglicht es uns, schnelle HTTP-Anforderungen verschiedener Methoden zu erstellen, die Antwort des Servers anzuzeigen und die Konfiguration für die Authentifizierung zu testen. Alle diese Funktionen werden beim Arbeiten mit der WP REST-API äußerst nützlich sein.
Das nächste, was wir auf unserem Server haben müssen, ist WP-CLI. Mit WP-CLI können wir unsere WordPress-Installation von der Konsole aus fernsteuern, ohne das Browserfenster öffnen zu müssen. Wir müssen WP-CLI im nächsten Teil dieser Serie verwenden, wenn Sie die Authentifizierung für OAuth 1.0a einrichten. Sie finden die Installationsanweisungen auf der offiziellen Website.
Neben einem HTTP-Client und WP-CLI benötigen wir auch Demo-Daten für unsere WordPress-Installation. Ich empfehle Ihnen, den Theme Unit Test (XML) oder das Demo Data Creator-Plugin auszuprobieren, mit dem Sie mehrere Beiträge, Seiten und Benutzer erstellen können.
Zum Zeitpunkt der Erstellung dieses Tutorials ist die aktuelle stabile Version 1.2.2, die im offiziellen Repository zu finden ist. In dieser Serie werden wir mit Version 2.0 arbeiten, da sie von Grund auf neu geschrieben wurde und viele bahnbrechende Änderungen enthält. Sie können die Beta der Version 2 von der offiziellen Plugin-Seite oder vom GitHub-Repository herunterladen.
Bitte beachten Sie, dass die Installation der aktuellen Betaversion in Ihrer Produktionsumgebung dringend empfohlen wird. Ich habe eine lokale WordPress-Umgebung eingerichtet und empfehle Ihnen, dies zu Entwicklungs- und Testzwecken zu tun.
Um das Plugin aus dem GitHub-Repository zu installieren, öffnen Sie Ihr Terminal und ziehen Sie das Plugin heraus, nachdem Sie Ihr Plugin geöffnet haben / wp-content / plugins / Verzeichnis:
$ git pull https://github.com/WP-API/WP-API.git
Das Plugin wird im heruntergeladen / WP-API / Verzeichnis.
Sie können es von Ihrem WordPress-Administrator aus aktivieren, um mit dem Testen fortzufahren.
Damit das WP REST API-Plugin funktioniert, müssen Sie mit WordPress ziemlich Permalinks aktivieren. Es wird hier davon ausgegangen, dass Sie diese grundlegende Aktion bereits kennen. Wenn Sie dies nicht tun, gibt es keine Sorgen, da WordPress.org Sie abgedeckt hat.
Nachdem das Plugin installiert wurde, können wir die Verfügbarkeit der API auf unserem Server überprüfen. Wir sind nicht darauf beschränkt, die API nur auf unserer Website zu verwenden. Sie verwenden sie auf jeder Website, auf der sie installiert und aktiviert ist. Um auf anderen Sites nach der API zu suchen, können Sie eine HEAD-Anfrage mit Ihrem HTTP-Client wie folgt an die Site senden:
$ HEAD http://someothersite.com/
Dies gibt im Antwortheader etwa Folgendes zurück:
Das Verknüpfung header verweist auf die Wurzelroute der WP API, die in unserem Fall die folgende ist:
http: // localserver / wordpress-api / wp-json /
Die API kann auch über JavaScript (oder jQuery) im Browser durch Abfragen des entsprechenden DOMs ermittelt werden Element wie das folgende:
(Funktion ($) var $ link = $ ('link [rel = "https://github.com/WP-API/WP-API"]'); var api_root = $ link.attr ('href') ;) (jQuery);Von hier aus können wir den Inhalt von der Site über die WP-REST-API abrufen. Bitte beachten Sie, dass nur authentifizierte Anforderungen den Inhalt der Website bearbeiten oder aktualisieren können, und ich möchte die Authentifizierung für die nächsten beiden Teile dieser Serie festlegen.
In diesem einleitenden Teil der Serie haben wir viel über die REST-Architektur, die WP-REST-API und HTTP selbst gelernt. Zuerst haben wir uns grundlegende Konzepte wie die REST-Architektur angesehen und wie Entwickler dabei helfen können, bessere Anwendungen zu erstellen. Dann haben wir etwas über HTTP, seine Verben und Antworttypen gelernt. Wir haben uns auch einen kurzen Überblick über APIs in WordPress und den Unterschied zwischen WP-REST-API und seinen Vorgängern gegeben.
Im letzten Teil dieses Tutorials haben wir das Plugin von GitHub installiert. Danach haben wir uns mit a vertraut gemacht KOPF Anfrage, mit der die Verfügbarkeit der API auf unserem Server sowie auf anderen Servern ermittelt werden kann.
Nachdem Sie die grundlegende Arbeitsumgebung eingerichtet haben, können Sie mit den Funktionen der WP REST-API arbeiten. Im nächsten Teil der Serie werden wir nach Möglichkeiten suchen, Authentifizierungsmethoden einzurichten, die von der API unterstützt werden. Diese Authentifizierungsmethoden sind erforderlich, wenn Sie eine Anforderung zum Abrufen, Erstellen, Aktualisieren oder Löschen von Inhalten senden. Also bleibt gespannt.
