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.