REST-API-Zweck?

Zunächst einmal verstehe ich, dass dies derzeit ein Plugin ist, aber es ist mit Sicherheit fast ein Teil von WordPress. Ich hoffe also, dass dies nicht als Off-Topic gekennzeichnet wird.

Ich habe ihre offiziellen Dokumente, viele andere Artikel gelesen und Tutorial-Videos angesehen, aber ich verstehe immer noch nicht, worauf es ankommt. Dies ist sicherlich die Zukunft von WordPress verschiedene Websites, aber: Was macht es nur für meine Website?

Bedenken Sie:

Ich arbeite gerade an den Kommentaren. Ich möchte, dass der Kommentarbereich nur geladen wird, wenn der Benutzer zum Kommentarbereich blättert (mit -200px Versatz, damit es keine Verzögerung gibt) .

• Ich werde einen Ajax-Aufruf auslösen, wenn der Benutzer zu diesem Punkt blättert
• Ajax Call sendet einige Daten mit, wie post_id etc
• Auf dem WP_Comment_Query()Server ausführen
• Senden Sie JSONDaten mit Kommentarbeziehungen, Namen, Inhalten usw. An den Kunden zurück
• Verwenden Sie JavaScript document.createElement(), innerHTML usw. zu erstellen und Ausgang Kommentare

Jetzt .. Warum sollte ich stattdessen die REST-API verwenden? Was nützt mir das? Nur zukunftssicher?

Ich müsste immer noch JavaScript verwenden, um alle Daten auszugeben, die ich erhalte. Ich habe keine guten Artikel gefunden, warum oder wofür ich die REST-API verwenden sollte (mit Ausnahme der Datenübertragung zwischen Websites und der Entwicklung mobiler Apps) .

Im jetzigen Zustand handelt es sich um ein schlecht entwickeltes Feature, das für einen kompetenten Entwickler keinen wirklichen Vorteil hat.

Die Grundidee zum Zeitpunkt der Erstellung dieser Antwort ist, die Kernfunktionalität von WordPress als JSON-REST-API bereitzustellen. Dies ermöglicht die Entkopplung der "Business" -Logik von WordPress von der Benutzeroberfläche und die Erstellung verschiedener vollständiger oder teilweiser Benutzeroberflächen zum Verwalten und Extrahieren von Informationen aus WordPress. Dies ist an sich keine Revolution, sondern eine Evolution. Nur ein Ersatz für die XML-RPC-API, die für sich genommen die HTTP-basierte API für die Übermittlung rationalisiert.

Wie bei jeder Evolution werden Sie sich bei jedem Schritt fragen, welchen Vorteil Sie vom früheren Zustand haben, und die Antwort lautet wahrscheinlich "nicht viel", aber hoffentlich häufen sich die Schritte zu einem großen Unterschied.

Warum also das negative Vorwort zu dieser Antwort? Weil ich als Softwareentwickler die Erfahrung gemacht habe, dass es selten möglich ist, eine generische API zu entwerfen, die tatsächlich nützlich ist, ohne dass konkrete Anwendungsfälle beantwortet werden müssen. Ein konkreter Anwendungsfall kann hier das Ersetzen der XML-RPC-API für die automatisierte WordPress-Verwaltung sein, aber jedes damit verbundene Front-End muss standortspezifisch sein, und da für jede vom Client an den Server gesendete Anforderung eine enorme Leistungseinbuße entsteht, ist dies nicht nur möglich Verwendung verschiedener APIs, um das gewünschte Ergebnis zu erzielen, sodass die Benutzer zufrieden sind. Für das Front-End bedeutet dies, dass bei nicht-trivialer Verwendung der Entwicklungsaufwand zwischen der Verwendung der AJAX-Route und der REST-API-Route weiterhin sehr gering ist.

Die beiden übergeordneten Vorteile sind:

1. Sie können (irgendwann) alle Verwaltungsaufgaben ohne die Verwaltungsoberfläche ausführen.
2. Sie können alle Daten für die Anzeige erhalten und das Front-End (und das Schreiben von PHP) vollständig entfernen.

In Bezug auf Ihr Beispiel speziell-

Ersetzen Sie die Schritte 3 und 4 durch die REST-API und ersetzen Sie die Schritte 1, 2 und 5 durch Backbone.js. BOOM, dynamische Webanwendung. Oder Sie können das komplexe Routing, das für Ihre Site erforderlich ist, einfacher mit Python ausführen.

Nun, eigentlich ein paar Dinge.

1. Hiermit können Sie bestimmte Funktionen nach Bedarf ausführen, anstatt die gesamte Berechnung eines gesamten Seitenladevorgangs durchführen zu müssen. Daher können Sie die Kommentare regelmäßig mit relativ geringem Aufwand aktualisieren, ohne dass eine Seitenaktualisierung erforderlich ist, indem Sie nur diesen API-Endpunkt aufrufen und die Daten auf Ihrer Seite aktualisieren. Dieses Konzept wird irgendwann in SPAs (Single-Page-Anwendungen) hochgerechnet, die die "Client" -Site schnell einmal laden und alle "Seitenänderungen" emulieren, ohne dass der HTML-Code der Seite jedes Mal neu abgerufen werden muss. Dies ist bereits mit dem Aufkommen von Frameworks wie Angular, Ember und React sehr beliebt. Sites reagieren möglicherweise blitzschnell, während sie gleichzeitig dem Endbenutzer Rechenleistung entziehen (Renderzyklus, Nicht-Geschäftslogik) und die Gesamtanzahl der Aufrufe an den Server erheblich reduzieren (nur die benötigten Daten abrufen).

2. Es trennt die Geschäftslogik und den Renderer. Ja, Sie können die API mit einer anderen PHP-Site verwenden, die die Ergebnisse ausspuckt, oder Sie können sie mit JavaScript verarbeiten, wie Sie es erwähnt haben, aber Sie können sie auch mit einer nativen mobilen Anwendung, Desktop-Anwendung usw. verwenden Einer von allen kommuniziert mit derselben API, die konsistent dieselbe Geschäftslogik ausführt, was wiederum für Konsistenz und Zuverlässigkeit bei den verschiedenen Clients sorgt, die die API verwenden.

APIs sind gut, weil sie die Belange von Logik und Anzeige trennen.

Die WordPress REST API ist das neue Highlight. Mit Anwendungen, die von js auf einer Seite gesteuert werden, und dem Wunsch von WordPress, eine App-Plattform zu werden, ist dies sehr sinnvoll. Es ist geplant, XML-RPC durch die REST-API zu ersetzen (was allein aus Sicherheitsgründen eine gute Sache ist!).

https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge-proposal/

• Die New York Times New Site ist offenbar darauf aufgebaut .
• Es ermöglicht mobilen Apps und anderen externen Diensten, auf wp-Inhalte (wie wp-cli ) zuzugreifen.
• Entwickler können damit ein einseitiges App-Front-End mit ihrem bevorzugten JSON-Framework der Woche erstellen und alle coolen Interaktionen direkt zur Hand haben.
• Es ermöglicht die Trennung von Bedenken (wie oben erwähnt) und eine größere Unabhängigkeit zwischen dem Back-End- und dem Front-End-Team.

Es ist ein weiterer Satz von Werkzeugen, um WordPress voranzutreiben. Und obwohl es ein mäandrierender Weg war, dorthin zu gelangen, denke ich, dass es sich lohnt, sich die Zeit zu nehmen, um es zu erforschen und zu verstehen.

Das Wichtigste zuerst - REST ist leicht

In einer Zeile - Wenn wir REST-APIs verwenden, rendern wir alle Daten auf Client-Seite (Schleifen, Bedingungen und serverseitige Aufrufe usw.) und sparen so Bandbreite. Gleichzeitig wird unsere Anwendung für jede mobile Plattform, für Integrationen von Drittanbietern und für modularisierte ( zwischen Frontend und Serverseite).

Willst du das nicht?

Zusätzlich zu den beiden genannten Hauptpunkten von @Milo verwende ich speziell die REST-API, um meine Daten für Nicht-WordPress-Anwendungen bereitzustellen. Wir haben eine Chrome-Erweiterung, die Informationen aus unserer WordPress-Datenbank abruft. Dies wird erreicht, indem REST-API-Endpunkte mit POST-Anforderungen verbunden werden.

BESTÄNDIGE Infrastruktur

Die REST-API ist konsistent und für den Benutzer lesbar. Es ist selbstdokumentierend.

GET wp-json/wp/v2/postsist ziemlich klar, was es tut. Es sind GETeinige Beiträge.

Sie haben einen Namespace:, wpeine Version: v2und eine Objektsammlungposts

Kannst du raten was: GET wp-json/wp/v2/posts/5tut? Wie wäre: GET wp-json/wp/v2/posts/5/comments Wie wäre es :GET wp-json/shop/v2/orders/345/lines/11/price

Ein Entwickler kann dies leicht erraten, da er den Preis für die bestellte Linie erhält 11, 345auch ohne die Dokumentation zu lesen. Der Entwickler kann sogar leicht erkennen, dass es vom shopPlugin kommt, da es einen Namensraum hat.

Wie wäre POST /wp-json/v2/posts title=New Blog Post es mitPUT /wp-json/v2/posts title=New Title

Das ist auch ziemlich klar. Es macht einen neuen Beitrag. Übrigens, es gibt die ID des neuen Beitrags zurück. Es geht nicht um AJAX ODER die REST-API. AJAX ist einfach eine Technologie, die auf die REST-API zugreift . Zuvor mussten Sie eine Reihe von abstrakten Ajax - Funktionsnamen ausarbeiten, z get_price_for_lineitem( $order, $line ). Wird das nur eine Zahl oder ein JSON-Objekt zurückgeben? Ich bin nicht sicher, wo die Dokumentation ist. Oh ... war der Ajax-Anruf get_order_line_priceoder get_lineitem_price.

Der Entwickler muss diese Entscheidungen nicht treffen, da die vorhandene wp-jsonAPI ein gutes Basismodell zum Erstellen eigener Endpunkte bietet . Sicher, ein Plugin- oder API-Entwickler kann gegen diese Regeln verstoßen, aber im Allgemeinen ist es einfacher, einem bereits festgelegten Standard zu folgen, und die meisten Entwickler würden lieber einem bereits festgelegten Muster folgen (siehe, wie weit verbreitet jQuery-Muster jetzt sind).

ABSTRAKTION ohne Ablenkung

Interessiert es mich, wie es POST /wp-json/mysite/v1/widgets title=Foobarfunktioniert? Nee. Ich möchte nur eine neue erstellen Widgetund ich möchte die ID zurück. Ich möchte es über ein Formular in meinem Frontend tun, ohne die Seite zu aktualisieren. Wenn ich eine URL anfordere, ist es mir egal, ob es sich um PHP, C #, ASP.NET oder eine andere Technologie handelt. Ich möchte nur ein neues Widget erstellen.

Die REST-API entkoppelt das Backend von der Front. Technisch gesehen können Sie, wenn Ihre API gut genug ist, Ihren gesamten Backend-Stack ändern. Solange Sie dieselbe REST-API-Struktur beibehalten, ist alles, was von der API abhängt, nicht betroffen.

Wenn Ihre REST-API einfach und konsistent genug ist und ein Substantiv wie Widgetseine Sammlung von Objekten und ein Substantiv / ein Bezeichner verwendet Widget/2, um eine einzelne Entität anzuzeigen, ist es wirklich einfach, diese API in einer völlig anderen Technologie zu schreiben, da es sich um mehr oder weniger grundlegende Datenbankinstallationen handelt Code.

Verwendet Standard-HTTP-Anforderungsverben.

REST-APIs nutzen den Kern der Funktionsweise des Webs und die VERBs (read: action), die Sie für die Zuordnung zu Standarddaten-CRUD-Funktionen verwenden.

CREATE : POST
READ   : GET
UPDATE : PUT/PATCH
DELETE : DELETE

Es gibt mehr HTTP-Verben, aber das sind die Grundlagen. Jede einzelne Anfrage über das Internet verwendet diese Verben. Eine REST-API befindet sich direkt über dem Modell, auf dessen Grundlage das Web Anforderungen erstellt. Keine Notwendigkeit für eine Kommunikationsschicht oder ein Abstraktionsmodell dazwischen. Es ist nur eine standardmäßige http-Anforderung an eine URL und gibt eine Antwort zurück. Einfacher geht es nicht.

Im Wesentlichen macht es einen Entwickler auf die Grundlagen der tatsächlichen Funktionsweise des Webs aufmerksam, und wenn Sie näher am Verständnis der Funktionsweise der zugrunde liegenden Protokolle sind, erhalten Sie ein effizienteres und besseres Produkt.