Une route REST enregistrée avec register_rest_route() ne se limite pas à un chemin et un callback : elle porte aussi un tableau d’arguments, un permission_callback, parfois un schéma complet, et cette définition entière reste consultable au moment de l’exécution. C’est ce que révèle get_attributes(), une méthode de WP_REST_Request peu documentée mais précieuse dès qu’un même contrôleur PHP doit servir plusieurs routes sans connaître à l’avance laquelle.
Ce que contient réellement la requête
Quand le serveur REST de WordPress résout une requête entrante, il ne se contente pas d’appeler le callback associé à la route qui correspond : il attache à l’objet WP_REST_Request, via set_attributes(), l’intégralité du tableau de définition qui a servi à enregistrer cette route. Ce tableau comprend notamment les méthodes HTTP acceptées, les arguments déclarés avec leur type et leur validation, le permission_callback, et tout élément supplémentaire ajouté lors de l’enregistrement.
get_attributes() restitue exactement ce tableau, sans transformation. C’est la seule façon fiable, depuis l’intérieur d’un callback, de savoir sur quelle route on se trouve réellement, plutôt que de le supposer d’après le nom de la fonction ou le chemin appelé.
function mon_controleur_generique( WP_REST_Request $request ) {
$attributs = $request->get_attributes();
// Exemple de structure retournée :
// array(
// 'methods' => array( 'GET' => true ),
// 'args' => array( 'id' => array( 'type' => 'integer', 'required' => true ) ),
// 'callback' => 'mon_controleur_generique',
// )
$args_declares = $attributs['args'] ?? array();
return rest_ensure_response( array( 'schema_recu' => array_keys( $args_declares ) ) );
}L’intérêt d’un contrôleur qui ne devine rien
Un projet headless finit souvent par déclarer plusieurs routes très proches, par exemple une variante publique et une variante réservée à un rôle éditorial d’un même contenu. Dupliquer le contrôleur pour chaque variante multiplie la maintenance ; le faire pointer vers une seule fonction, qui adapte son comportement selon les arguments réellement déclarés pour la route appelée, réduit cette duplication sans sacrifier la clarté du schéma exposé à chaque route.
get_attributes() rend ce genre de contrôleur générique possible sans recourir à des conventions de nommage fragiles. La fonction n’a pas besoin d’ouvrir un fichier de configuration séparé ni de relire rest_get_server() pour retrouver la définition de sa propre route : elle est déjà là, portée par la requête elle-même.
Un usage typique en validation croisée
Un cas concret : un contrôleur qui accepte un tri (orderby) doit vérifier que la valeur demandée fait bien partie de celles déclarées dans le schéma de la route, sans dupliquer cette liste dans le corps du callback. En lisant les arguments via get_attributes(), la liste des valeurs autorisées reste une source unique de vérité, déjà validée une première fois par rest_validate_value_from_schema() lors du routage.
function verifier_orderby( WP_REST_Request $request ) {
$attributs = $request->get_attributes();
$schema_arg = $attributs['args']['orderby'] ?? array();
$valeurs_ok = $schema_arg['enum'] ?? array();
$demande = $request->get_param( 'orderby' );
if ( ! empty( $valeurs_ok ) && ! in_array( $demande, $valeurs_ok, true ) ) {
return new WP_Error( 'orderby_invalide', 'Valeur de tri non autorisée pour cette route.', array( 'status' => 400 ) );
}
return true;
}Ce type de vérification, placé par exemple dans un permission_callback partagé par plusieurs routes, tire toute sa force du fait qu’il ne recopie jamais la liste des valeurs autorisées : il la lit là où elle a été déclarée une seule fois.
Les limites à connaître
Cette méthode ne remplace pas get_route(), qui donne le chemin réellement demandé, ni get_schema() d’un contrôleur, qui décrit la ressource retournée plutôt que la route elle-même. get_attributes() concerne uniquement la définition d’enregistrement de la route en cours, telle que fournie à register_rest_route(). Elle peut aussi renvoyer un tableau incomplet si la route a été enregistrée de façon minimaliste, sans arguments déclarés : dans ce cas, un contrôleur générique doit prévoir des valeurs par défaut plutôt que de supposer une structure toujours complète.
- Consulter get_attributes() pour connaître dynamiquement le schéma déclaré, sans dupliquer sa définition
- Ne pas l’utiliser comme substitut à get_route() lorsque seul le chemin importe
- Prévoir des valeurs par défaut robustes si la route a été enregistrée sans arguments détaillés
Une route bien déclarée porte sa propre documentation ; get_attributes() ne fait que la lire au bon moment plutôt que de la faire répéter ailleurs.
En résumé
Dans un contrôleur REST partagé par plusieurs routes d’un projet headless, deviner le contexte d’exécution à partir de conventions de nommage est fragile et difficile à maintenir. get_attributes() offre un accès direct à la définition exacte de la route en cours, telle qu’enregistrée, ce qui permet d’écrire des callbacks réellement génériques, capables de valider ou d’adapter leur comportement à partir d’une unique source de vérité plutôt que d’une hypothèse implicite sur le contexte.
