rest_request_after_callbacks
Définition : rest_request_after_callbacks est un filtre WordPress appliqué après l’exécution des callbacks d’une route REST. Il permet d’examiner ou d’ajuster le résultat avant les étapes ultérieures de réponse.
Comprendre et utiliser
À quoi sert cette notion ?
Il sert à mesurer un traitement, assurer un nettoyage ciblé ou modifier une réponse lorsque le contrat de l’endpoint l’autorise.
Fonctionnement technique
Le filtre reçoit le résultat, le gestionnaire et la requête. Les demandes qui échouent avant la résolution d’un endpoint ne passent pas nécessairement par cette étape.
Dans quel contexte l’utiliser ?
Une extension vérifie que la route de démonstration renvoie les champs publics attendus sans toucher aux autres routes.
Étude de cas : application professionnelle
Après l’exécution de la callback, une extension peut vouloir examiner le résultat pour contrôler un contrat ou libérer une ressource. Le filtre rest_request_after_callbacks fournit ce point d’intervention, mais ne doit pas transformer une erreur en succès. Tester une réponse 200 et un WP_Error, puis vérifier que le client voit toujours leurs codes respectifs. Dans une API publique, une modification transversale du JSON peut casser des consommateurs existants. Il vaut souvent mieux corriger l’endpoint concerné que modifier toutes les réponses via un filtre global.
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_request_after_callbacks', function ( $response, $handler, $request ) {
if ( '/atoolpha/v1/demo' === $request->get_route() ) {
// Examiner la réponse sans la modifier.
}
return $response;
}, 10, 3 );Décryptage du code et résultat attendu
Le filtre conserve le résultat pour éviter une régression. Dans une instrumentation réelle, les diagnostics seraient collectés séparément avec des données non sensibles.
Exercice guidé pour vérifier la notion
Comparer un endpoint produisant une réussite et une erreur de validation et observer les statuts des résultats traversant le filtre.
Précautions et limites
Ne pas remplacer une erreur d’autorisation par une réponse 200. Des opérations internes peuvent encore intervenir après ce filtre.
À ne pas confondre
after_callbacks suit les callbacks de l’endpoint ; pre_serve_request intervient plus près de l’émission HTTP finale.
Diagnostic avancé
Une modification inattendue du JSON peut provenir d’un filtre après callbacks ; inspecter les extensions qui le manipulent.
Choix d’architecture et déploiement
Limiter les changements transverses de réponses : ils peuvent casser les clients qui dépendent du schéma officiel d’un endpoint.
