Share
Dans cette série, nous avons examiné la wp_remote_get La fonction API HTTP de WordPress afin de comprendre son fonctionnement, son utilisation et les arguments optionnels acceptés.
À partir de là, nous pouvons écrire des demandes détaillées. cependant, ce n'est que la moitié - il y a aussi la réponse.
Dans le deuxième article, nous avons examiné l’aspect d’une réponse de base, son évaluation et son affichage à l’écran, mais nous n’avons pas parlé de la réponse en détail..
Si vous souhaitez écrire des requêtes plus avancées et écrire un code plus défensif, il est important de comprendre les données envoyées en réponse. Dans ce dernier article, nous allons faire exactement cela.
Premièrement, il est important de comprendre ce que je veux dire par écriture de code défensif: lors de l’écriture de logiciels, nous devons souvent nous attaquer aux cas dans lesquels un utilisateur peut faire quelque chose de mal, une saisie peut être mal définie, ou des données peuvent être récupérées ou reçues - telles que dans le cas d'une réponse - de manière incorrecte.
À cette fin, nous codons défensivement contre ces scénarios afin que notre logiciel ne tombe pas totalement en panne ou bombarde lorsque l’utilisateur l’utilise. Au lieu de cela, il échoue gracieusement et continue à fonctionner.
En sachant ce que la fonction reçoit exactement en réponse à sa demande, nous savons quelles données rechercher, puis comment gérer avec élégance le cas où il ne revient pas comme prévu..
Afin de préparer le terrain à quoi s’attendre, examinons un exemple de réponse. Disons que vous devez faire un OBTENIR demande à une URL qui vous renverra un peu de texte.
De manière générale, vous pouvez vous attendre à faire des demandes plus complexes où la réponse peut être XML ou JSON ou autre chose; toutefois, toutes ces informations seront définies dans le corps index du tableau de réponse. Donc, si vous comprenez à quoi vous attendre, alors vous comprenez comment le gérer.
Cela dit, voici la réponse que vous pourriez recevoir d'une simple requête à un domaine qui ne renvoie que du texte brut.
Array ([headers] => Array ([date] => jeu., 30 sept. 2010 15:16:36 GMT [serveur] => Apache [x-powered-by] => PHP / 5.3.3 [serveur x] => 10.90.6.243 [expires] => jeu., 30 septembre 2010 03:16:36 GMT [cache-control] => Array ([0] => no-store, no-cache, must-revalidate [1] = > post-vérification = 0, pré-vérification = 0) [varier] => accepter-encoder [contenu-longueur] => 1641 [connexion] => fermer [type de contenu] => application / php) [corps] = > 'Un simple morceau de texte.' [Réponse] => Array ([code] => 200 [message] => OK) [cookies] => Array ())
Rien de plus qu'un tableau (ou, en réalité, un tableau de tableaux). Rien aussi mauvais, droit?
Passons en revue chacun des éléments de réponse en détail.
Comme vous pouvez le constater d'après la réponse ci-dessus, les en-têtes sont en réalité composés d'un autre tableau constitué d'autres informations..
Avant d'examiner chacune des informations ci-dessus, il est important de comprendre ce qu'est exactement un en-tête. En bref, les en-têtes fournissent des informations sur la communication requête / réponse existant 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 qui nous aident tous à obtenir des informations non seulement sur la requête, mais également sur le serveur avec lequel nous sommes. communicant.
Cela dit, regardons chaque élément d'en-tête en détail.
De toute évidence, il s'agit d'un élément exceptionnellement facile à comprendre: En termes simples, il s'agit de la date et de l'heure auxquelles le message a été envoyé. Il comprend évidemment le jour, la date et l'heure, tous en heure de Greenwich, qui est une norme de temps globale.
L'élément serveur fait référence au type de logiciel sur lequel le serveur est exécuté. Plus souvent qu'autrement, vous êtes susceptible de voir Apache; Cependant, il existe d’autres applications serveur disponibles aujourd’hui, telles que IIS et la prochaine version de Nginx..
X-Powered-By désigne le logiciel serveur qui alimente la transaction de la communication. Dans notre cas, nous voyons PHP, ce qui signifie simplement que notre demande a été envoyée à un serveur exécutant Apache et PHP..
Cela peut ne pas toujours être le cas, bien que.
Par exemple, vous pouvez finir par communiquer avec un serveur exécutant nginx et Python, ou un autre type de logiciel serveur exécutant Ruby on Rails..
Cet élément de réponse particulier fait référence à l'adresse IP du serveur auquel la demande est envoyée. J'ai rarement eu besoin de connaître cette information particulière; Toutefois, si vous obtenez une réponse inattendue en dépit du fait que toutes les autres informations sont en ordre, il peut être utile de savoir si l'adresse IP du serveur correspond à celle que vous attendez du domaine auquel la demande est envoyée..
Chaque fois qu'une demande est faite et qu'une réponse est envoyée, la réponse a une durée de vie, pour ainsi dire.
Plus spécifiquement, la réponse sera considérée comme "périmée" après un certain temps. De toute évidence, le moment auquel la réponse est considérée comme périmée est celui où la réponse est dite expirée.
La durée pendant laquelle une réponse est considérée comme non périmée dépend de la configuration du serveur, mais l'horodatage est du même format que la date de la demande..
Cache-control fait référence à la notion selon laquelle un navigateur Web (ou un autre mécanisme de cache mis en place entre le client et le serveur) peut ou non utiliser la première réponse comme réponse à des requêtes futures..
Par exemple, si un serveur répond avec no-cache, cela signifie alors que le navigateur, le serveur ou tout autre logiciel proxy ou mécanisme de mise en cache de la machine requérante doit traiter chaque réponse comme une nouvelle réponse. Si, par contre, no-cache est ne pas spécifiée, la première réponse peut être la seule réponse que vous pouvez obtenir (au moins jusqu'à ce que le cache soit défini pour expirer).
Cela consiste évidemment en deux index:
Accentsconagua
no-cache a été mis enpost-vérification et la pré-vérification intervalle à expiré, une nouvelle version des données sera demandée; sinon, une version en cache sera récupérée.Cet aspect particulier de la mise en cache sort du cadre de cette série, car beaucoup plus pourrait ê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 en ce qu’elle indique aux serveurs demandeurs comment traiter les demandes ultérieures similaires..
En règle générale, cela indiquera au serveur si une réponse en cache peut être utilisée ou si une nouvelle valeur doit être extraite. C’est un autre élément qui peut devenir excessivement compliqué, mais pour essayer de résumer l’explication en quelque chose qui est un peu plus à la portée de ce dont nous discutons, l’élément en-tête de variation peut également indiquer au serveur les différents types de contenu que le client peut traiter.
Ainsi, dans l'exemple ci-dessus, nous indiquons au serveur que notre client est capable de traiter des informations codées..
Content-length est un concept simple avec un seul gotcha: tout d'abord, il définit simplement la longueur du corps de la réponse.
Le fait est que cela se fait en octets 8 bits. Cela signifie que la réponse n'est pas fournie en kilo-octets, mégaoctets ou autre forme de données que nous avons l'habitude de voir..
À cette fin, vous devrez peut-être effectuer certaines conversions si vous souhaitez collecter des informations plus riches sur les données renvoyées..
La valeur de connexion spécifie le type de connexion que le navigateur demandeur préférerait. 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 alternatives. Par exemple, vous pouvez recevoir "Keep-Alive" qui, évidemment, souhaite maintenir la connexion active pendant un certain temps.
Encore une fois, c’est là un autre exemple de ce qui nécessiterait que son propre article fasse l’objet d’une discussion approfondie; cependant, cela donne un aperçu du type de connexion que le serveur préfère, ce qui peut vous aider à construire de futures requêtes..
C'est vraiment seulement pertinent à la fois POSTER et POUSSER demandes. En bref, cela définit le type de corps des requêtes.
Cela peut varier en fonction des données envoyées. Parfois, il peut s'agir d'une URL encodée, parfois de PHP, parfois de quelque chose d'autre. Quoi qu’il en soit, cela nous permet de vérifier que les données renvoyées dans le contenu correspondent à ce que nous attendons de notre part..
L'élément body contient en fait les informations renvoyées par le serveur..
Dans notre exemple de 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 pourrait revenir sous forme de données binaires nécessitant un niveau de désérialisation.
Quel que soit le cas, nous, responsables de la mise en œuvre de la demande, devons savoir comment décoder correctement la réponse avant de l'afficher à nos utilisateurs..
La réponse fait en réalité référence au code de réponse HTTP envoyé par le serveur au client demandeur. Si vous n'êtes pas familier avec les codes d'état HTTP, je vous recommande de vérifier HTTPStat.us pour une référence vraiment bonne.
En bref, une réponse est composée d’un code numérique et d’un message textuel indiquant le résultat de la demande..
Dans l'exemple ci-dessus, vous pouvez voir que nous avons reçu le code d'état "200" et le message "OK". La paire code et message doit toujours être synchronisée.
Cela signifie que si vous recevez un "403", vous devriez également recevoir un "Interdit" ou, si vous recevez un "404", vous devriez recevoir un message "introuvable"..
Personnellement, j’ai trouvé que ces valeurs étaient importantes pour diagnostiquer les problèmes rencontrés avec les demandes que j’avais faites..
Enfin, le tableau de cookies fait référence à toutes les informations qui ont été envoyées par le réseau en fonction des cookies existant entre le client et le serveur actuels qui effectuent la communication..
Selon la nature de votre demande, cela peut être ou ne pas être vide - cela varie trop au cas par cas pour fournir un guide définitif. En bref, si aucun cookie n’a été établi entre les deux connexions, celui-ci sera probablement toujours vide; sinon, les données composant le tableau de cookies seront spécifiquement basées sur les cookies existant entre les deux services..
Dans l’ensemble, il y a une bonne quantité de données et volonté varie d'une requête à l'autre en fonction de ce que vous demandez de recevoir et de la réponse du serveur; Cependant, le fait est que vous savez maintenant quoi attendre et comment gérer correctement tous les cas.
Si votre travail empire, vous pouvez toujours utiliser un débogueur ou simplement placer des instructions de débogage, telles que print_r ou var_dump afin de voir ce que le serveur renvoie afin de pouvoir gérer les erreurs avec élégance.
Nous reviendrons plus tard sur l'API HTTP WordPress pour examiner d'autres méthodes telles que wp_remote_post et wp_remote_request afin que nous obtenions une image complète de l'API HTTP.
Jusque-là, cette série vous aura fourni, espérons-le, autant de couverture en profondeur de wp_remote_get pour vous aider non seulement à améliorer votre travail, mais également à éveiller votre curiosité pour les autres possibilités en matière de demandes à distance.
