Comment une route REST unique peut-elle remplacer des dizaines de fiches statiques d’hébergements maintenues à la main depuis des années ? C’est la question à laquelle cet office de tourisme régional a dû répondre en refondant son site, en remplaçant un empilement de pages WordPress classiques par un type de contenu structuré, consommé par un front Nuxt.
Chaque hébergement — chambre d’hôtes, gîte, camping — existait auparavant comme une page indépendante, avec une mise en forme variable selon la personne qui l’avait créée des années plus tôt. Le nouveau projet imposait une structure homogène, capable d’être filtrée par type d’hébergement et par commune, sans dépendre du gabarit visuel du thème.
Structurer l’hébergement comme un type de contenu à part entière
Le type de contenu hebergement a été déclaré avec deux taxonomies personnalisées associées, l’une pour le type de logement, l’autre pour la commune de rattachement :
register_post_type( 'hebergement', array(
'label' => 'Hébergements',
'public' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'thumbnail', 'custom-fields' ),
) );
register_taxonomy( 'type_hebergement', 'hebergement', array(
'label' => 'Type d\'hébergement',
'show_in_rest' => true,
'hierarchical' => true,
) );
register_taxonomy( 'commune', 'hebergement', array(
'label' => 'Commune',
'show_in_rest' => true,
'hierarchical' => false,
) );Une route dédiée plutôt que la route générique
La route native /wp/v2/hebergement aurait suffi pour un simple listing, mais le front Nuxt avait besoin d’un format agrégé, avec les taxonomies déjà résolues en texte lisible plutôt qu’en identifiants numériques à recroiser côté client :
register_rest_route( 'tourisme/v1', '/hebergements', array(
'methods' => 'GET',
'callback' => 'tourisme_get_hebergements',
'permission_callback' => '__return_true',
) );
Filtrer par commune et par type dès la requête
La callback accepte des paramètres de filtrage, transmis directement aux arguments de WP_Query, pour éviter au front de devoir filtrer côté client une liste complète à chaque changement de critère.
function tourisme_get_hebergements( $request ) {
$args = array(
'post_type' => 'hebergement',
'posts_per_page' => 50,
);
if ( $request->get_param( 'commune' ) ) {
$args['tax_query'] = array( array(
'taxonomy' => 'commune',
'field' => 'slug',
'terms' => $request->get_param( 'commune' ),
) );
}
$query = new WP_Query( $args );
return rest_ensure_response( $query->posts );
}Ce que le filtrage par taxonomie a changé pour l’équipe éditoriale
Avant cette refonte, savoir combien d’hébergements existaient dans une commune donnée obligeait à parcourir manuellement le listing complet des pages, sans aucun compteur fiable. La taxonomie commune, une fois en place, a permis d’ajouter un simple widget dans l’administration WordPress affichant le nombre de fiches par commune, directement utile à l’équipe de l’office de tourisme pour ses statistiques internes.
Ce bénéfice, non prévu au départ du projet, illustre un effet secondaire fréquent d’une bonne structuration en taxonomies : elle profite autant à l’API consommée par le front qu’aux usages internes de l’équipe éditoriale, sans travail supplémentaire une fois la taxonomie correctement déclarée.
Le choix de consommer la route par lot
Le front Nuxt, plutôt que d’appeler la route fiche par fiche au moment de la navigation, récupère l’ensemble des hébergements d’une commune en un seul appel lors de l’affichage de la page de commune, puis affiche les fiches individuelles à partir de ce lot déjà en mémoire côté client, sans requête supplémentaire.
- Un seul appel par page de commune, plutôt qu’un appel par fiche affichée
- Taxonomies résolues côté serveur pour éviter un recroisement côté front
- Pagination limitée à cinquante éléments pour éviter une réponse trop volumineuse
Structurer un contenu en type dédié avec ses propres taxonomies coûte du temps au démarrage d’un projet, mais ce temps se rembourse dès le premier filtre demandé par le client.
En résumé
Le passage d’un empilement de pages libres à un type de contenu structuré, exposé par une route REST agrégée, a permis à cet office de tourisme de livrer un front rapide et facilement filtrable, sans complexité excessive côté serveur. Ce cas ne traite pas la question du multilingue, qui nécessiterait une réflexion distincte sur la duplication ou non des fiches par langue.
