L'un des défis liés à l'écriture d'une série sur une API - ou même une partie d'une API - est qu'il est difficile de couvrir tous les aspects de cette API sans passer trop de temps à plonger dans une partie et à essayer simultanément de ne pas survoler le sommet de chaque API sans donner suffisamment d'informations pratiques.
Exemple: au cours de la dernière série, nous nous sommes penchés sur l'API HTTP WordPress. Plus précisément, nous avons couvert wp_remote_get
et wp_remote_post
, et nous avons effectué des travaux relativement importants avec les deux fonctions, y compris des exemples de projets de construction.
Le problème, c’est qu’il reste encore beaucoup à faire dans l’API HTTP de WordPress. À l'avenir, nous pourrons peut-être faire une série avancée sur davantage d'aspects de l'API, mais pour l'instant, passons en revue tout ce que nous avons couvert dans cette série..
Écrire une série relativement longue sur quelques fonctions peut couvrir beaucoup de terrain. Le problème, c'est que si, à un moment quelconque dans le futur, vous devez vous référer à une partie, vous pouvez ne pas vous rappeler exactement où l'information a été localisée..
Ou peut-être pire, vous devrez peut-être parcourir une quantité importante d'informations pour trouver le seul aspect dont vous avez besoin pour continuer à progresser dans votre travail..
Bien sûr, vous pouvez toujours vous référer à l'index des séries, mais afin de vous donner un "guide rapide", j'ai pensé qu'il pourrait être utile de résumer les articles, les fonctions et les notes de haut niveau concernant le segment de l'API. que nous avons couvert au cas où vous auriez besoin d'une référence pour votre travail.
Bien sûr, notez que vous pouvez toujours voir la série dans son intégralité sur la page de liste des séries..
Avant de passer en revue chacune des fonctions, rappelez-vous qu’une demande distante peut être définie comme le processus par lequel un serveur envoie une demande à un autre serveur..
En règle générale, un serveur peut simplement envoyer des données à l’autre serveur, qui faire quelque chose avec lui (que ce soit enregistrer les données, traiter les données, etc.), et il peut éventuellement renvoyer une réponse.
À un haut niveau, c'est une demande à distance. Pour plus d'informations sur cette idée particulière, assurez-vous de consulter ce post.
wp_remote_get
wp_remote_get
est une fonction qui fait partie de l'API HTTP WordPress qui est responsable de la fabrication OBTENIR
demandes.
La fonction accepte:
Si vous êtes principalement responsable de récupération informations du serveur, alors c’est la fonction que vous voulez utiliser.
Deuxièmement, si vous avez besoin de plus que d'une URL ou de davantage de contrôle sur la demande envoyée, vous pouvez consulter cet article pour examiner tous les arguments qu'il accepte..
Suivant dans la série, nous avons construit un plugin réel qui tirerait parti wp_remote_get
afin que nous puissions récupérer le nombre d'abonnés pour un compte Twitter donné, ainsi que le dernier tweet envoyé à partir dudit compte Twitter.
L’objectif principal de cet article et de cette démonstration était de donner un exemple pratique de la façon d’utiliser wp_remote_get
dans un "monde réel". Pour le code source complet de la démonstration, assurez-vous de lire l’article associé..
Parce que wp_remote_get
est axé sur récupération informations, il est logique que nous attendions une réponse, non? Dans le dernier article couvrant wp_remote_get
, nous avons examiné ce qui est exactement renvoyé par le serveur et comment WordPress le formate pour notre usage.
Si, au cours de votre travail, vous avez des difficultés à déchiffrer exactement ce qui revient du serveur (ou la raison pour laquelle cela ne fonctionne pas comme prévu), vous devez consulter cet article..
wp_remote_post
Tout comme wp_remote_get
est responsable de faire OBTENIR
demandes, wp_remote_post
est responsable de faire POSTER
demandes.
Comme avec le wp_remote_get
, wp_remote_post
accepte les mêmes arguments:
Mais il y a une différence fondamentale dans le but de cette fonction et dans la précédente qui a été discutée. La différence est ce qui se passe lorsque la demande est complétée.
Tout comme wp_remote_get
est principalement utilisé pour récupérer Les données, wp_remote_post
est utilisé pour envoyer données sur le réseau à traiter - une réponse ne peut jamais être renvoyée.
Pour l’étude initiale de cette fonction particulière - ce qu’elle accepte, y compris la liste avancée d’arguments - consultez cet article..
Comme nous l'avons fait avec wp_remote_get
, nous avons créé un plugin pour démontrer comment wp_remote_post
fonctionne dans le contexte plus large d'un thème WordPress.
Bien que le plugin soit sur GitHub pour référence, nous parcourons toute la première version du plugin dans l'article suivant. Plus précisément, nous expliquons comment faire la demande à un script chargé de recevoir $ _POST
données et puis comment il peut formater et renvoyer une réponse à l'appelant.
Dans le dernier article de la série, nous avons complété le plug-in en utilisant LESS pour lui donner une apparence légèrement plus agréable. Nous avons complété le plug-in afin qu'il enregistre certaines des données de réponse dans la base de données, juste pour donner une idée. quant à la façon dont cela peut être réalisé.
Les posts de synthèse sont un nouveau territoire - du moins pour moi - comme je l’ai toujours laissé de côté, mais j’ai pensé que ce serait une bonne référence à fournir étant donné que nous avons couvert autant de terrain dans la série..
Recommencer:
wp_remote_get
code source wp_remote_post
projet sur GitHub Cela dit, faites-moi savoir si vous préférez les messages de synthèse ou non. Comme je l’ai dit, c’est quelque chose que je ne fais généralement pas, mais si cela peut vous servir de référence, alors je suis heureux de continuer à le faire pour les futures séries ".