Objectif de l'API REST?

Tout d'abord, je comprends qu'il s'agit d'un plugin à l'heure actuelle, mais il fait très certainement presque partie de WordPress de toute façon. J'espère donc que cela ne sera pas signalé comme hors sujet.

J'ai lu leurs documents officiels, beaucoup d'autres articles et regardé des vidéos de didacticiel, mais je n'obtiens toujours pas certains points .. C'est certainement l'avenir de WordPress, il est très pratique pour le développement d'applications mobiles et l'utilisation / le partage de données entre différents sites mais: qu'est-ce que cela fait pour mon site uniquement?

Considère ceci:

Im travaille actuellement sur les commentaires. Je veux que la section de commentaire ne se charge que lorsque l'utilisateur fait défiler jusqu'à la section de commentaire (avec un décalage de -200px, afin qu'il n'y ait pas de retard) .

• Je vais déclencher un appel ajax lorsque l'utilisateur défile jusqu'à ce point
• L'appel Ajax envoie des données avec lui, comme post_id etc
• Exécuter WP_Comment_Query()sur le serveur
• Renvoyer les JSONdonnées au client avec les relations de commentaires, les noms, le contenu, etc.
• Utilisez JavaScript document.createElement(), innerHTML etc. pour créer et produire des commentaires

Maintenant .. Pourquoi devrais-je utiliser l'API REST à la place? Quelle est l'utilité pour moi? Juste à l'épreuve du temps?

J'aurais encore besoin d'utiliser JavaScript pour sortir toutes les données que j'obtiens .. Je n'ai trouvé aucun bon article pourquoi ou pour quoi je devrais utiliser l'API REST (sauf le transfert de données entre les sites et le développement d'applications mobiles) ..

Dans son état actuel, c'est une fonctionnalité mal conçue qui n'a pas de réel avantage pour un développeur compétent.

L'idée de base, telle qu'elle se présente au moment où cette réponse est écrite, est d'exposer les fonctionnalités principales de WordPress en tant qu'API JSON REST. Cela permettra de découpler la logique "métier" de WordPress de l'interface utilisateur et de créer différentes interfaces utilisateur complètes ou partielles pour gérer et extraire des informations de wordpress. Ce n'est pas en soi une révolution, mais une évolution. juste un remplacement de l'API XML-RPC qui, en soi, rationalise en quelque sorte l'API HTTP pour la soumission.

Comme pour toute évolution, à chaque étape, vous pourriez vous demander quel avantage tirez-vous de l'ancien état, et la réponse est probablement «pas beaucoup», mais j'espère que les étapes s'accumulent pour faire une grande différence.

Alors pourquoi la préface négative de cette réponse? Parce que mon expérience en tant que développeur de logiciels est qu'il est rarement possible de concevoir une API générique qui soit réellement utile sans avoir de cas d'utilisation concrets auxquels répondre. Un cas d'utilisation concret ici peut être de remplacer l'API XML-RPC pour la gestion automatisée de wordpress, mais tout front-end lié doit être spécifique au site et puisqu'il y a une énorme pénalité de performances pour chaque demande envoyée du client au serveur, vous ne pouvez pas simplement utilisation agrégée de différentes API pour obtenir le résultat souhaité de manière à ce que les utilisateurs restent satisfaits. Cela signifie que pour le frontal, pour une utilisation non triviale, il y aura toujours très peu de différence dans l'effort de développement entre l'utilisation de la route AJAX et la route REST-API.

Les deux principaux avantages sont les suivants:

1. Vous pouvez (éventuellement) effectuer toutes les tâches d'administration sans l'interface d'administration.
2. Vous pouvez obtenir toutes les données à afficher et éliminer complètement le frontal (et écrire PHP).

Concernant votre exemple spécifiquement-

Remplacez les étapes 3 et 4 par l'API REST et remplacez les étapes 1, 2 et 5 par Backbone.js. BOOM, application web dynamique. Ou peut-être êtes-vous plus à l'aise de faire le routage complexe nécessaire pour votre site avec Python à la place.

Eh bien, quelques choses en fait.

1. Il vous permet d'exécuter des fonctions spécifiques selon vos besoins, plutôt que d'exiger tout le calcul d'un chargement de page entier. Ainsi, vous pouvez mettre à jour les commentaires périodiquement avec des frais généraux assez faibles sans avoir besoin d'une actualisation de la page en appelant simplement ce point de terminaison API et en mettant à jour les données sur votre page. Ce concept sera finalement extrapolé dans les SPA (applications à page unique) qui chargent rapidement le site "client" une fois et émule tous les "changements" de page sans avoir à ressaisir le HTML de la page à chaque fois. Ceci est déjà très populaire avec l'avènement de frameworks tels que Angular, Ember et React. Les sites peuvent répondre avec une vitesse fulgurante, tout en déchargeant une partie de la puissance de calcul pour l'utilisateur final (cycle de rendu, logique non commerciale) et en réduisant considérablement le nombre total d'appels vers le serveur (ne tirez que les données dont vous avez besoin,

2. Il sépare la logique métier et le rendu. Oui, vous pouvez utiliser l'API avec un autre site PHP en crachant les résultats, ou le gérer avec Javascript comme vous l'avez mentionné, mais vous pouvez également le consommer avec une application mobile native, une application de bureau, etc. Non seulement cela, mais vous pourriez avoir l'un de tous parle à la même API, qui exécute systématiquement la même logique métier, ce qui crée à son tour une cohérence et une fiabilité entre les différents clients utilisant l'API.

Les API sont bonnes car elles séparent les préoccupations de logique et d'affichage.

L'API WordPress REST est la nouvelle nouveauté. Avec des applications pilotées par une seule page js, et WordPresses souhaite devenir une plate-forme d'application, cela a beaucoup de sens. Le plan est de remplacer XML-RPC par l'API REST (ce qui est une bonne chose pour des raisons de sécurité uniquement!)

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

• Apparemment , le nouveau site de New York Times est construit dessus .
• Il permet aux applications mobiles et autres services externes d'accéder au contenu wp (comme wp-cli )
• Il permet aux développeurs de créer un front-end d'application d'une seule page avec leur framework de consommation JSON préféré de la semaine, et d'avoir toutes les interactions intéressantes à portée de main.
• Il permet la séparation des préoccupations (comme mentionné ci-dessus) et une plus grande indépendance entre les équipes back-end et front-end.

C'est un autre ensemble d'outils pour faire avancer WordPress. Et, même si cela a été un voyage sinueux pour arriver là où nous sommes, je pense que cela vaut la peine de prendre le temps de l'explorer et de le comprendre.

Tout d'abord - REST est léger

En une seule ligne - Lorsque nous utilisons des API REST, nous effectuons tout le rendu des données côté client (boucles, conditions et appels côté serveur, etc.) en économisant de la bande passante et en même temps, notre application est prête pour toute plate-forme mobile, intégrations tierces et modularisée ( séparation des préoccupations entre le côté serveur et le côté serveur).

Tu ne veux pas ça?

En plus des 2 grands points mentionnés par @Milo, j'utilise spécifiquement l'API REST pour exposer mes données à des applications non WordPress. Nous avons une extension Chrome qui extrait des informations de notre base de données WordPress, et cela est accompli en frappant les points de terminaison de l'API REST avec des requêtes POST.

Infrastructure cohérente

L'API REST est cohérente et lisible par l'homme. C'est auto-documenté.

GET wp-json/wp/v2/postsest assez clair ce qu'il fait. Ce GETsont des articles.

Vous avez un espace de noms:, wpune version: v2et une collection d'objetsposts

Pouvez-vous deviner quoi GET wp-json/wp/v2/posts/5? Que diriez-vous: GET wp-json/wp/v2/posts/5/comments Que diriez-vous:GET wp-json/shop/v2/orders/345/lines/11/price

Un développeur peut facilement deviner en regardant cela, il obtiendra le prix de la ligne 11sur commande 345même sans lire la documentation. Le développeur peut même facilement dire qu'il vient du shopplugin car il est à espace de noms.

Que POST /wp-json/v2/posts title=New Blog Post diriez-vousPUT /wp-json/v2/posts title=New Title

C'est aussi assez clair. Il fait un nouveau message. Soit dit en passant, il renvoie l'ID du nouveau message. Il ne s'agit pas d'AJAX OU de l'API REST. AJAX est simplement une technologie qui accède à l'API REST. Considérant que, avant, vous devez venir avec un tas de noms abstraits de la fonction ajax comme: get_price_for_lineitem( $order, $line ). Est-ce que ça va retourner juste un nombre ou un objet JSON? Je ne sais pas où est la documentation. Oh ... était l'appel ajax get_order_line_priceouget_lineitem_price .

Le développeur n'a pas à prendre ces décisions, car l' wp-jsonAPI existante fournit un bon modèle de base à suivre lors de la création de vos propres points de terminaison. Bien sûr, un développeur de plugin ou d'api peut enfreindre ces règles, mais en général, il est plus facile de suivre un standard qui a déjà été défini et la plupart des développeurs préfèrent de loin suivre un modèle déjà défini (voir à quel point les modèles jQuery sont omniprésents maintenant).

ABSTRACTION sans distraction

Est-ce que je me soucie du POST /wp-json/mysite/v1/widgets title=Foobarfonctionnement? Nan. Je veux juste en créer un nouveau Widgetet je veux l'ID en retour. Je veux le faire à partir d'un formulaire sur mon front-end sans rafraîchir la page. Si je fais une demande à une URL, je me fiche que ce soit PHP, C #, ASP.NET ou toute autre technologie. Je veux juste créer un nouveau widget.

L'API REST découple le backend de l'avant. Techniquement, si votre API est suffisamment bonne, vous pouvez modifier l'intégralité de votre pile backend. Tant que vous conservez la même structure d'API REST, tout ce qui dépend de l'API n'est pas affecté.

Si votre API REST est assez simple et cohérente, en utilisant un nom comme Widgetsune collection d'objets et un nom / identifiant comme Widget/2pour indiquer une seule entité, il est vraiment simple d'écrire cette API dans une technologie très différente car il s'agit d'une plomberie de base de données plus ou moins basique code.

Utilise les verbes de requête HTTP standard.

Les API REST exploitent le cœur du fonctionnement du Web et les VERBES (lire: action) que vous utilisez mappent aux fonctions CRUD de données standard.

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

Il y a plus de verbes HTTP, mais ce sont les bases. Chaque demande sur Internet utilise ces verbes. Une API REST se trouve juste au-dessus du modèle, le Web est construit sur demande. Pas besoin de couche de communication ou de modèle d'abstraction entre les deux. Il s'agit simplement d'une requête http standard vers une URL et elle renvoie une réponse. Vous ne pouvez pas obtenir beaucoup plus simple que cela.

Essentiellement, cela rend un développeur plus conscient des rouages ​​du fonctionnement du Web et lorsque vous vous rapprochez de la compréhension du fonctionnement des protocoles sous-jacents, vous finissez par créer un meilleur produit plus efficace.