# get_attributes() de WP_REST_Request : la définition de la route en cours

> Un contrôleur REST générique n'a pas besoin de deviner sur quelle route il tourne : get_attributes() de WP_REST_Request lui donne directement accès à la définition complète enregistrée pour cette route.

- Auteur : WordPress Développement
- Publié le : 2026-10-07
- Mis à jour le : 2026-09-30
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/get-attributes-wp-rest-request-schema-route/

## L’essentiel

- Chaque route REST enregistrée porte ses propres arguments, callbacks et schéma
- Ces informations sont attachées à la requête au moment du routage
- get_attributes() les rend accessibles depuis n'importe quel callback

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

> L'essentiel à retenir : Chaque route REST enregistrée porte ses propres arguments, callbacks et schéma ; Ces informations sont attachées à la requête au moment du routage ; get_attributes() les rend accessibles depuis n'importe quel callback

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.