Cliquer sur un lien, soumettre un formulaire, charger une image de fond en CSS : chacune de ces actions envoie, sans que l’utilisateur ne le voie, une requête HTTP structurée vers un serveur. Elle précise toujours au minimum une méthode (l’action voulue) et une URL (la ressource visée), et souvent des en-têtes complémentaires et un corps de données pour les envois de formulaires ou d’API.
Émettre une requête depuis WordPress
Un thème ou une extension qui doit contacter un service externe construit sa propre requête HTTP sortante avec wp_remote_get(), wp_remote_post() ou la fonction plus générale wp_remote_request(), qui accepte de préciser la méthode. Dans l’autre sens, chaque visite d’une page WordPress est elle-même une requête HTTP entrante que le serveur web transmet à PHP, qui la traduit en objets exploitables via les superglobales $_GET, $_POST ou, plus proprement dans l’API REST, via l’objet WP_REST_Request.
Exemple
POST /wp-json/wp/v2/posts HTTP/1.1
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
{"title":"Nouvel article","status":"draft"}Pièges fréquents
- Envoyer des données sensibles (mot de passe, jeton) dans l’URL d’une requête
GET: elle se retrouve alors dans les journaux du serveur et l’historique du navigateur, contrairement à un corps de requêtePOST. - Oublier l’en-tête
Content-Type: application/jsonlors d’un appel à l’API REST avec un corps JSON : sans lui, WordPress peut mal interpréter les données envoyées. - Confondre les paramètres de l’URL (
?page=2) avec le corps de la requête : les premiers sont visibles et limités en taille, le second peut transporter des volumes de données bien plus importants.