Après chaque requête, le serveur ne renvoie pas seulement du HTML ou du JSON brut : il l’accompagne d’un code résumant l’issue de l’opération et d’en-têtes précisant comment interpréter ce qui suit. C’est cet ensemble — statut, en-têtes, corps — qui constitue la réponse HTTP, la partie du dialogue que l’on inspecte le plus souvent en cas de bug d’affichage ou d’API.
Lire une réponse WordPress
Quand un thème appelle une API tierce via wp_remote_get(), la fonction renvoie un tableau (ou un objet WP_Error en cas d’échec réseau) dont on extrait le corps avec wp_remote_retrieve_body() et le code de statut avec wp_remote_retrieve_response_code(). Côté navigateur, l’onglet « Réseau » des outils de développement affiche la réponse complète de chaque requête vers /wp-json/, très utile pour déboguer une extension qui communique avec l’API REST.
Exemple
HTTP/1.1 200 OK
Content-Type: application/json
{"id":42,"title":{"rendered":"Bonjour"}}Bon à savoir
- Un code 200 n’implique pas forcément un contenu correct : une API mal conçue peut renvoyer une erreur applicative dans le corps JSON tout en gardant un statut 200, une pratique à éviter mais fréquente.
- Le corps d’une réponse peut être vide (par exemple pour un
DELETEréussi), seul le code de statut informe alors du résultat. - Les outils comme Postman ou l’extension navigateur correspondante permettent d’inspecter une réponse complète sans écrire de code, utile pour comprendre une API avant de l’intégrer.
- Une réponse volumineuse mal compressée (sans en-tête
Content-Encoding: gzip) ralentit inutilement le temps de chargement perçu par le visiteur, surtout sur une connexion mobile.