Dans cette série, nous examinons la fonction wp_remote_get
API HTTP WordPress pour comprendre son fonctionnement, comment l'utiliser et les paramètres facultatifs qu'elle accepte.
À partir de là, nous pouvons rédiger une demande détaillée, mais ce n'est que la moitié - il y a aussi la réponse.
Dans le deuxième article, nous avons examiné à quoi ressemble une réponse de base, comment l'évaluer et comment l'afficher à l'écran, mais nous n'avons pas réellement discuté de la réponse en détail. p>
Si vous souhaitez écrire des requêtes plus avancées et écrire du code plus défensif, il est important de comprendre les données envoyées en réponse. C’est exactement ce que nous ferons dans le dernier article.
Tout d'abord, il est important de comprendre ce que j'entends par écrire du code défensif : lors de l'écriture d'un logiciel, nous devons souvent faire face à des situations dans lesquelles l'utilisateur peut faire quelque chose de mal, la saisie peut être mal définie ou les données peuvent être récupérées ou reçues - par exemple dans un cas de réponse - incorrect.
À cette fin, nous codons de manière défensive pour ces scénarios afin que notre logiciel ne plante pas complètement ou ne plante pas pendant que l'utilisateur l'utilise. Au lieu de cela, il échoue normalement et continue de fonctionner.
En sachant exactement ce qu'une fonction reçoit en réponse à sa requête, nous savons quelles données rechercher, puis comment gérer la situation avec élégance lorsqu'elle ne renvoie pas comme prévu.
Pour savoir à quoi s’attendre, examinons un exemple de réponse. Disons que vous souhaitez faire une requête GET
vers une URL, qui vous renverra un simple morceau de texte.
De manière générale, vous pouvez faire une requête plus complexe où la réponse peut être XML ou JSON ou autre chose, cependant, toutes ces informations seront définies dans l'index body
du tableau de réponse. Donc, si vous savez à quoi vous attendre, vous savez comment y faire face.
Cela dit, c'est la réponse que vous attendez d'une simple requête adressée au domaine, qui ne renvoie que du texte brut.
Array ( [headers] => Array ( [date] => Thu, 30 Sep 2010 15:16:36 GMT [server] => Apache [x-powered-by] => PHP/5.3.3 [x-server] => 10.90.6.243 [expires] => Thu, 30 Sep 2010 03:16:36 GMT [cache-control] => Array ( [0] => no-store, no-cache, must-revalidate [1] => post-check=0, pre-check=0 ) [vary] => Accept-Encoding [content-length] => 1641 [connection] => close [content-type] => application/php ) [body] => 'A simple bit of text.' [response] => Array ( [code] => 200 [message] => OK ) [cookies] => Array() )
n'est rien de plus qu'un tableau (ou en fait un tableau de tableaux). Rien aussi de mal, non ?
Examinons chaque élément réactif en détail.
Comme vous pouvez le voir dans la réponse ci-dessus, l'en-tête est en fait constitué d'un autre tableau contenant des informations supplémentaires.
Avant d’examiner chaque information ci-dessus, il est important de comprendre ce qu’est exactement un en-tête. En termes simples, les en-têtes fournissent des informations sur la communication requête/réponse qui existe entre le client et le serveur.
Il existe une grande variété d'en-têtes qui peuvent être renvoyés (dont beaucoup dépassent le cadre de cet article), mais tous nous aident à obtenir des informations non seulement sur la requête, mais également sur le serveur de la requête. Nous communiquons.
Cela dit, examinons chaque élément d'en-tête en détail.
Évidemment, c'est un élément très simple à comprendre : simplement, il s'agit de la date et de l'heure auxquelles le message a été envoyé. Il inclut évidemment le jour de la semaine, la date et l’heure au moyen de l’heure de Greenwich, qui est l’étalon horaire mondial.
L'élément serveur fait référence au type de logiciel exécuté par le serveur. En règle générale, vous verrez probablement Apache, mais d'autres applications serveur sont désormais disponibles, telles que IIS et le prochain nginx.
X-Powered-By fait référence au logiciel serveur qui prend en charge les transactions de communication. Dans notre cas, nous voyons PHP, ce qui signifie simplement que nos requêtes sont envoyées à un serveur exécutant Apache et PHP.
Mais ce n’est pas toujours le cas.
Par exemple, vous pourriez finir par communiquer avec des serveurs exécutant nginx et Python, ou d'autres types de logiciels serveur exécutant Ruby on Rails.
Cet élément de réponse spécifique fait référence à l'adresse IP du serveur auquel la requête a été envoyée. J'ai rarement besoin de connaître ces informations spécifiques ; cependant, si vous obtenez une réponse inattendue alors que toutes les autres informations semblent être en ordre, il peut être utile de savoir si l'adresse IP du serveur correspond au domaine auquel vous souhaitez que la demande soit envoyée. . a aidé.
Chaque fois qu'une demande est faite et qu'une réponse est envoyée, on peut dire que la réponse a un cycle de vie.
Plus précisément, les réponses seront considérées comme « périmées » après un certain temps. Évidemment, le moment où une réponse est considérée comme périmée est le moment où elle est considérée comme expirée.
L'heure à laquelle une réponse est considérée comme non périmée dépend de la configuration du serveur, mais l'horodatage est au même format que la date de la demande.
Cache Control fait référence au concept selon lequel un navigateur Web (ou tout autre mécanisme de mise en cache existant entre le client et le serveur) peut ou non utiliser la première réponse comme réponse aux requêtes futures. p>
Par exemple, si la réponse du serveur no-cache
,则意味着请求机器的浏览器、服务器或其他代理软件或缓存机制必须将每个响应视为新响应。另一方面,如果 no-cache
n'est pas spécifiée, la première réponse peut être la seule réponse que vous pourrez obtenir (au moins jusqu'à l'expiration du cache
Ceci est évidemment constitué de deux index :
no-cache
s'il a été définipost-check
和 pre-check
a expiré, une version mise à jour des données sera demandée ; sinon, la version mise en cache sera récupérée ; Cet aspect spécifique de la mise en cache dépasse le cadre de cette série, car beaucoup plus peut être écrit et expliqué. Cependant, la définition ci-dessus devrait suffire à expliquer les en-têtes que vous voyez ;
Cette valeur d'en-tête est similaire à l'en-tête Cache-Control dans la mesure où elle indique au serveur demandeur comment gérer les demandes ultérieures similaires.
D'une manière générale, cela indiquera au serveur si une réponse mise en cache peut être utilisée ou si une nouvelle valeur doit être récupérée. C'est un autre élément qui peut devenir trop complexe, mais pour essayer de distiller l'explication dans une portée plus large de ce dont nous parlons, différents éléments d'en-tête peuvent également indiquer au serveur les différents types de contenu recherchés par le serveur. Client peut le gérer.
Donc, dans l'exemple ci-dessus, nous indiquons au serveur que notre client est capable de gérer les informations codées.
Content-length est un concept simple avec un inconvénient : tout d'abord, il définit simplement la longueur du corps de la réponse.
Le problème est qu'il le fait en octets de 8 bits. Cela signifie que la réponse n'est pas fournie en kilo-octets, en mégaoctets ou dans toute forme de données que nous voyons normalement.
Pour ce faire, vous devrez peut-être effectuer certaines transformations si vous souhaitez collecter des informations plus riches sur les données renvoyées.
La valeur de connexion spécifie le type de connexion préféré par le navigateur demandeur. Ci-dessus, nous voyons que la valeur est définie comme "close", ce qui signifie qu'une fois la réponse envoyée, la connexion peut être fermée.
Cependant, il existe d'autres options. Par exemple, vous pourriez recevoir « keep-alive », qui souhaite évidemment maintenir la connexion active pendant un certain temps.
C'est encore un autre exemple qui nécessiterait son propre article pour être discuté en détail ; cependant, cela donne un aperçu des types de connexions que le serveur préfère, ce qui peut vous aider à formuler de futures demandes.
Cela ne concerne en réalité que les demandes POST
和 PUSH
. En bref, cela définit le type de corps de la requête.
Cela peut varier en fonction des données envoyées. Parfois, il peut s'agir d'une URL codée, parfois de PHP, parfois d'autre chose. Quoi qu'il en soit, cela permet de garantir que nous pouvons vérifier que les données renvoyées dans le contenu correspondent à ce que nous attendions en fonction de la demande.
body contient en fait les informations renvoyées par le serveur.
Dans les exemples des deux articles précédents, nous avons reçu une chaîne JSON de Twitter. Dans l'exemple ci-dessus, nous recevons une simple chaîne de texte. En fin de compte, la réponse peut être renvoyée sous forme de données binaires, nécessitant un certain degré de désérialisation.
Quoi qu'il en soit, il est de notre responsabilité en tant que responsables de la mise en œuvre de la demande de comprendre comment décoder correctement la réponse avant de l'afficher à l'utilisateur.
Une réponse fait en fait référence au code de réponse HTTP renvoyé du serveur au client demandeur. Si vous n'êtes pas familier avec les codes d'état HTTP, je vous recommande de consulter HTTPStat.us pour une très bonne référence.
En bref, une réponse se compose d'un code numérique et d'un message texte indiquant le résultat de la demande.
Dans l'exemple ci-dessus, vous pouvez voir que nous avons reçu un code d'état « 200 » et un message « OK ». La correspondance des codes et des messages est toujours synchronisée les unes avec les autres.
Cela signifie que si vous recevez un « 403 », vous devriez également recevoir un message « Interdit », ou si vous recevez un « 404 », vous devriez également recevoir un message « Non trouvé ».
Personnellement, je trouve que ces valeurs spécifiques sont très importantes pour diagnostiquer si quelque chose ne va pas avec une demande que je fais.
Enfin, le tableau de cookies fait référence à toute information envoyée sur le réseau en fonction des cookies qui existent entre le client actuel et le serveur avec lequel il communique.
Selon la nature de votre demande, celle-ci peut être vide ou non - cela varie trop au cas par cas pour fournir des indications claires. En bref, si aucun cookie n'est établi entre deux connexions, alors la connexion sera très probablement toujours vide ; sinon, les données qui composent le tableau des cookies seront basées exclusivement sur les cookies qui existent entre les deux services.
Dans l'ensemble, la quantité de données est assez importante, et en fonction de ce que vous demandez à recevoir et de la réponse du serveur, les données varieront d'une requête à l'autre. Cependant, le problème est que vous savez maintenant à quoi vous attendre et comment ; traiter tous les cas correctement.
Si les choses empirent pour vous, vous pouvez toujours utiliser un débogueur ou simplement mettre des instructions de débogage comme pour voir ce que le serveur renvoie afin que vous puissiez gérer l'erreur avec élégance. print_r
或 var_dump
afin d'avoir une compréhension complète de l'API HTTP. wp_remote_post
和 wp_remote_request
D'ici là, nous espérons que cette série vous fournira l'introduction la plus approfondie possible à wp_remote_get
qui vous aidera non seulement à améliorer votre travail, mais éveillera également votre curiosité quant à ce qui est possible d'autre en termes de demandes à distance.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!