# register_post_type et show_in_rest : exposer un contenu métier sans extension

> Pas besoin d'un plugin d'API tierce pour connecter une application externe à un contenu métier : l'argument show_in_rest de register_post_type suffit souvent.

- Auteur : Clément Hadrot
- Publié le : 2025-01-15
- Mis à jour le : 2025-01-15
- Catégorie : Tips
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tips/register-post-type-show-in-rest-exposer-contenu-metier/

## L’essentiel

- show_in_rest active automatiquement un point de terminaison REST
- rest_base personnalise le chemin exposé
- Champs personnalisés à ajouter séparément

`register_post_type( 'commande_client', array( 'show_in_rest' => true ) )` : cette seule ligne, ajoutée à la déclaration d'un type de contenu personnalisé, suffit à exposer l'ensemble de ses données via l'API REST native de WordPress, sans installer la moindre extension supplémentaire.

Un développeur qui doit connecter une application externe (un outil de gestion interne, une application mobile, un tableau de bord) à un contenu métier propre à un client pense souvent, par réflexe, à chercher un plugin d'API REST personnalisée. Dans une large majorité des cas, l'API REST déjà intégrée au cœur de WordPress répond parfaitement au besoin.

## Ce que fait réellement show_in_rest

Depuis WordPress 4.7, chaque type de contenu peut être exposé automatiquement sous forme de point de terminaison REST, à condition de déclarer l'argument `show_in_rest` à `true` lors de son enregistrement. WordPress crée alors les routes de lecture, création, modification et suppression, avec la gestion des permissions déjà intégrée.

```
register_post_type( 'commande_client', array(
    'label'        => 'Commandes',
    'public'       => true,
    'show_in_rest' => true,
    'rest_base'    => 'commandes',
    'supports'     => array( 'title', 'custom-fields' ),
) );
```

Le point de terminaison résultant, `/wp-json/wp/v2/commandes`, expose immédiatement la liste des commandes au format JSON, avec pagination, tri et filtres déjà pris en charge par le cœur de WordPress.

## Personnaliser le chemin exposé

> L'essentiel à retenir : show_in_rest active automatiquement un point de terminaison REST ; rest_base personnalise le chemin exposé ; Champs personnalisés à ajouter séparément

Sans l'argument `rest_base`, WordPress utilise par défaut le nom technique du type de contenu comme chemin d'API, ce qui donne parfois des URL peu lisibles pour l'application externe qui consomme les données. Préciser `rest_base` permet d'exposer un chemin distinct, plus proche du vocabulaire métier utilisé par l'équipe cliente.

## Exposer aussi les champs personnalisés

Par défaut, seuls les champs natifs (titre, contenu, statut, date) apparaissent dans la réponse JSON. Les champs personnalisés, qu'ils soient créés via l'API native des métadonnées ou via un plugin de champs, doivent être déclarés explicitement pour apparaître dans la sortie REST.

```
register_post_meta( 'commande_client', 'montant_total', array(
    'show_in_rest' => true,
    'single'       => true,
    'type'         => 'number',
) );
```

Cette déclaration s'appuie sur `register_post_meta()`, une fonction native indépendante de tout plugin, ce qui garantit la portabilité de l'ensemble sur un futur changement d'hébergeur ou de configuration serveur.

## Restreindre la visibilité publique

- `public => false` combiné à `show_in_rest => true` pour un contenu interne non indexé
- `show_in_rest => array( 'controller_class' => ... )` pour un contrôleur personnalisé si les permissions par défaut ne suffisent pas
- Filtrage explicite via `rest_prepare_{post_type}` pour retirer un champ sensible de la réponse

## Un contrôleur sur mesure quand c'est nécessaire

Pour des cas où la logique métier dépasse une simple exposition de champs, un contrôleur REST personnalisé, dérivé de `WP_REST_Controller`, reste possible en le déclarant via l'option `controller_class` de `show_in_rest`. Cela évite d'écrire des routes REST entièrement manuelles quand seule la logique de lecture doit être adaptée.

> Avant d'écrire une seule route REST personnalisée, vérifiez toujours ce que `show_in_rest` propose déjà : réinventer une route qui existe nativement coûte du temps de maintenance sans bénéfice réel.

## Documenter le point de terminaison pour l'équipe externe

Une fois le contenu exposé, la route apparaît automatiquement dans le schéma général accessible via `/wp-json/`, ce qui permet à l'équipe qui développe l'application externe de découvrir la structure attendue sans documentation écrite à maintenir séparément.

## En résumé

Avant de chercher un plugin d'API tierce, l'argument `show_in_rest` mérite toujours d'être testé en premier : il couvre la grande majorité des besoins d'exposition de contenu métier, avec un code minimal et sans dépendance externe. L'authentification des requêtes vers ce point de terminaison reste un sujet à part, qui mérite un traitement dédié selon le niveau de sensibilité des données exposées.