rest_pre_serve_request
Définition : rest_pre_serve_request est un filtre WordPress exécuté juste avant l’envoi d’une réponse REST. Il indique si le résultat a déjà été servi et permet un contrôle très avancé du rendu final.
Comprendre et utiliser
À quoi sert cette notion ?
Il intervient dans les cas exceptionnels où une extension doit prendre en charge l’émission de la réponse elle-même, au lieu du serveur REST standard.
Fonctionnement technique
Le filtre reçoit un booléen served, une réponse, la requête et le serveur. Retourner true signale au Core de ne pas émettre lui-même la réponse.
Dans quel contexte l’utiliser ?
Une extension de streaming spécialisée peut nécessiter un autre mécanisme de sortie ; un glossaire ordinaire n’en a aucune utilité.
Étude de cas : application professionnelle
La dernière étape d’une réponse REST concerne son émission réelle vers le client. rest_pre_serve_request permet exceptionnellement de gérer cette émission, mais retourner true signifie prendre la responsabilité d’envoyer le résultat. Pour comprendre le danger, garder d’abord le filtre entièrement passif et comparer le JSON avant et après activation. Un développeur qui retourne true sans produire le corps peut créer une réponse vide malgré un contrôleur fonctionnel. Dans un glossaire documentaire, ce hook doit être expliqué, pas activé : aucune fonctionnalité de publication des fiches ne dépend de cette interception.
Exemple technique commenté
Cet extrait est destiné à un fichier PHP chargé par WordPress, idéalement dans un plugin local de test. Il ne doit pas être placé dans l'éditeur de contenu. Avant exécution, vérifier que les objets et variables mentionnés existent dans le contexte et que les permissions nécessaires sont définies.
<?php
add_filter( 'rest_pre_serve_request', function ( $served, $result, $request, $server ) {
// Conserver le comportement standard de WordPress.
return $served;
}, 10, 4 );
Décryptage du code et résultat attendu
L’exemple est volontairement passif : il laisse le serveur émettre le JSON normalement. Il n’implémente pas une sortie personnalisée.
Exercice guidé pour vérifier la notion
Observer une route de test avec le filtre neutre, puis vérifier que le corps JSON et les en-têtes restent inchangés.
Précautions et limites
Ne jamais retourner true sans avoir réellement émis la réponse complète et cohérente ; cela peut produire un corps vide ou une réponse cassée.
À ne pas confondre
Ce filtre concerne la transmission finale ; rest_request_after_callbacks traite un stade précédent du pipeline.
Diagnostic avancé
Si un endpoint répond avec un corps vide alors que la callback renvoie des données, inspecter la valeur served et les filtres de sortie.
Choix d’architecture et déploiement
Préférer WP_REST_Response pour contrôler statut et en-têtes. Réserver l’interception de la transmission à des besoins exceptionnels vérifiés.
