objectif de l'API REST?

15

Tout d’abord, j’ai bien compris qu’il s’agissait d’un plugin au stade actuel, mais qu’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 leur documentation officielle, de nombreux autres articles et visionné des vidéos de tutoriels, mais je ne comprends 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 de / partage de données entre différents sites, mais: que fait-il uniquement pour mon site?

Considérez ceci:

Je travaille actuellement sur les commentaires. Je souhaite que la section de commentaires ne soit chargée que lorsque l'utilisateur sélectionne la section de commentaires (avec un décalage de -200px, afin d'éviter tout délai) .

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

Maintenant .. Pourquoi utiliserais-je plutôt l'API REST? Quelle est l'utilisation pour moi? Juste pour l'avenir?

J'aurais toujours besoin d'utiliser JavaScript pour générer toutes les données que je reçois. Je n'ai trouvé aucun bon article ni pourquoi ni pour quoi utiliser une API REST (sauf le transfert de données). entre les sites et le développement d’applications mobiles) ..

    
posée N00b 02.03.2016 - 18:50

7 réponses

6

Dans son état actuel, il s'agit d'une fonctionnalité mal conçue qui ne présente aucun avantage réel pour un développeur compétent.

L’idée de base, au moment où cette réponse est écrite, est d’exposer les fonctionnalités de base 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 les 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 un peu l'API basé sur HTTP pour la soumission.

Comme pour toute évolution, à chaque étape, vous pouvez vous demander quel avantage tirez-vous de l'ancien État, et la réponse est probablement "pas beaucoup", mais espérons que les étapes s'accumulent à une grande différence.

Alors pourquoi la préface négative de cette réponse? En tant que développeur de logiciels, mon expérience est qu’il est rarement possible de concevoir une API générique qui soit réellement utile sans avoir à répondre à des cas d’utilisation concrets. Un cas d’utilisation concret peut ici remplacer l’API XML-RPC pour la gestion automatisée de wordpress, mais toute interface frontale doit être spécifique à un site et comme il existe une pénalité en termes de performances pour chaque demande envoyée du client au serveur, vous ne pouvez pas simplement utilisation globale de différentes API pour obtenir le résultat souhaité de manière à ce que les utilisateurs restent satisfaits. Cela signifie que, pour une utilisation frontale et non triviale, les efforts de développement entre l’utilisation de la route AJAX et celle de l’API-REST seront très minimes.

    
réponse donnée Mark Kaplun 03.03.2016 - 01:58
3

Les deux principaux avantages sont les suivants:

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

En ce qui concerne votre exemple en particulier -

Remplacez les étapes 3 & 4 avec l'API REST et remplacez les étapes 1, 2 et 5 par Backbone.js. BOOM, application web dynamique. Ou peut-être préférez-vous effectuer le routage complexe nécessaire à votre site avec Python.

    
réponse donnée Milo 02.03.2016 - 19:55
3

Eh bien, quelques petites choses en fait.

  1. Il vous permet d’exécuter des fonctions spécifiques selon vos besoins, plutôt que de demander tout le calcul d’un chargement de page complet. Ainsi, vous pouvez mettre à jour les commentaires régulièrement avec un temps de traitement assez faible sans avoir besoin d'actualiser la page en appelant simplement ce point de terminaison d'API et en mettant à jour les données de votre page. Ce concept sera finalement extrapolé dans des SPA (applications à page unique) qui chargent le site "client" rapidement et une fois, et émulent toutes les "modifications" de page sans avoir à extraire à nouveau le code HTML de la page. C'est déjà très populaire avec l'avènement de frameworks tels que Angular, Ember et React. Les sites peuvent répondre à une vitesse fulgurante, tout en déchargeant une partie de la puissance de calcul vers l'utilisateur final (cycle de rendu, logique non professionnelle) et en réduisant considérablement le nombre total d'appels au serveur (n'extrayez que les données dont vous avez besoin, au lieu de recharger tout à chaque fois).

  2. Il sépare la logique métier et le rendu. Oui, vous pouvez utiliser l'API avec un autre site PHP générant les résultats, ou le manipuler avec Javascript comme vous l'avez mentionné, mais vous pouvez également le consommer avec une application mobile native, une application de bureau, etc. De plus, vous pourriez avoir chacun d'entre eux communiquant avec la même API, qui applique systématiquement la même logique métier, ce qui crée cohérence et fiabilité pour les différents clients utilisant l'API.

Les API sont bonnes car elles séparent les problèmes de logique et d’affichage.

    
réponse donnée Colt McCormack 02.03.2016 - 22:05
2

L'API WordPress REST est le nouveau point chaud. Avec les applications à page unique gérées par WordPress et le désir de WordPresses de devenir une plate-forme d'applications, cela a beaucoup de sens. L'objectif est de remplacer XML-RPC par l'API REST (ce qui est une bonne chose pour des raisons de sécurité uniquement!)

enlace

  • Le nouveau site New York Times est construit sur ce site, apparemment .
  • Il permet aux applications mobiles et à d'autres services externes d'accéder au contenu wp (comme wp-cli )
  • Il permet aux développeurs de créer une application frontale d’une seule page avec leur JSON consommant cadre favori de la semaine, et ont tous les interactions fraîches au bout des doigts.
  • Cela 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, bien que le chemin parcouru pour nous rendre où nous en sommes a été périlleux, je pense que cela vaut la peine de prendre le temps de l'explorer et de le comprendre.

    
réponse donnée Jeremy Ross 02.09.2016 - 20:27
1

Tout d'abord, REST est léger

En une ligne - Lorsque nous utilisons des API REST, nous effectuons tous 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 (problème entre frontend et côté serveur).

Vous ne voulez pas ça?

    
réponse donnée Divyanshu Jimmy 12.08.2017 - 07:31
0

Outre les deux points intéressants mentionnés par @Milo, j'utilise spécifiquement l'API REST pour exposer mes données à des applications autres que WordPress. Nous avons une extension Chrome qui extrait des informations de notre base de données WordPress. Pour ce faire, vous devez atteindre les points de terminaison de l'API REST avec des requêtes POST.

    
réponse donnée Nick F 02.03.2016 - 21:00
0

Infrastructure cohérente

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

GET wp-json/wp/v2/posts est très clair sur ce qu'il fait. Il GET s des messages.

Vous avez un espace de noms: wp , une version: v2 et une collection d'objets posts

Pouvez-vous deviner quoi: GET wp-json/wp/v2/posts/5 fait? Que diriez-vous de: GET wp-json/wp/v2/posts/5/comments Que diriez-vous de: 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 11 à la commande 345 même sans lire la documentation. Le dev peut même facilement dire qu’il provient du plugin shop car il est espacé.

Que diriez-vous de POST /wp-json/v2/posts title=New Blog Post Que diriez-vous de PUT /wp-json/v2/posts title=New Title

C'est assez clair aussi. Cela fait un nouveau post. En passant, il retourne l'ID du nouveau poste. Il ne s'agit pas d'AJAX OU de l'API REST. AJAX est simplement une technologie à laquelle accède à l'API REST. Tandis que, auparavant, vous auriez à trouver un tas de noms de fonctions abstraites en ajax comme:   get_price_for_lineitem( $order, $line ) . Est-ce que cela va renvoyer juste un nombre, ou un objet JSON? Je ne suis pas sûr, où est la documentation. Oh ... était l'appel ajax get_order_line_price ou get_lineitem_price .

Le développeur n'est pas obligé de prendre ces décisions, car le wp-json api existant 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 plug-in ou d'api peut enfreindre ces règles, mais en général, il est plus facile de suivre une norme déjà définie 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 à présent).

ABSTRACTION sans distraction

Est-ce que je me soucie du fonctionnement de POST /wp-json/mysite/v1/widgets title=Foobar ? Nan. Je veux juste créer un nouveau Widget et 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, peu importe si c'est PHP, C #, ASP.NET ou toute autre technologie. Je veux juste créer un nouveau widget.

L'API REST dissocie le backend de l'avant. Techniquement, si votre API est suffisamment performante, vous pouvez modifier l'intégralité de votre pile d'arrière-plan. Tant que vous conservez la même structure d'API REST, tout ce qui en dépend ne sera pas affecté.

Si votre API REST est assez simple et cohérente, utilisez un nom tel que Widgets en tant que collection d'objets et nom / identificateur tel que Widget/2 pour indiquer une entité unique, il est très simple d'écrire cette API dans un format très différent. la technologie car il s'agit d'un code de plomberie de base de données plus ou moins basique.

Utilise les verbes de requête HTTP standard.

Les API REST exploitent le coeur du fonctionnement du Web et les VERBs (read: action) que vous utilisez en correspondance avec les fonctions CRUD de données standard.

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

Il existe plus de verbes HTTP, mais ce sont les bases. Chaque requête sur Internet utilise ces verbes. Une API REST est située au-dessus du modèle. Le Web est construit sur des requêtes. 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, qui renvoie une réponse. Vous ne pouvez pas obtenir beaucoup plus simple que cela.

Essentiellement, cela permet aux développeurs de mieux comprendre le fonctionnement réel du Web. Lorsque vous vous approchez du fonctionnement des protocoles sous-jacents, vous améliorez l'efficacité du produit.

    
réponse donnée Armstrongest 07.12.2017 - 02:37

Lire d'autres questions sur les étiquettes