Un front éditorial affiche-t-il l’historique des modifications d’un article, ou uniquement sa version publiée la plus récente ? Cette question, anodine en apparence, détermine si l’API REST de WordPress doit exposer ou non la route des révisions, un point que beaucoup de projets headless ne tranchent jamais explicitement, laissant le comportement par défaut de WordPress décider à leur place.
Ce que WordPress expose par défaut
Chaque article, page, ou type de contenu personnalisé qui déclare show_in_rest dispose automatiquement d’une sous-route de révisions, de la forme /wp/v2/posts/<id>/revisions. Cette route n’est toutefois accessible qu’aux utilisateurs disposant de la capacité edit_post sur le contenu concerné : un visiteur anonyme qui tente d’y accéder reçoit une erreur rest_cannot_read avec un code HTTP 401, jamais la liste des révisions.
GET /wp-json/wp/v2/posts/42/revisions
// Réponse pour un visiteur non authentifié :
{
"code": "rest_cannot_read",
"message": "Vous n'êtes pas autorisé à consulter les révisions de ce contenu.",
"data": { "status": 401 }
}Pour un utilisateur authentifié disposant des droits d’édition, chaque révision apparaît avec son contenu complet, son auteur et sa date, dans l’ordre chronologique inverse.
Pourquoi cette route reste peu utilisée en headless
La plupart des fronts découplés n’ont besoin que de la version publiée d’un contenu, celle renvoyée par la route principale /wp/v2/posts/<id>. Les révisions intéressent surtout deux cas d’usage bien plus rares : un outil d’administration éditoriale construit par-dessus l’API (un tableau de bord personnalisé qui affiche l’historique d’un article aux rédacteurs), ou un mécanisme de restauration piloté depuis un front d’administration distinct du site public.
Exposer volontairement un historique éditorial
Pour un projet où le front doit afficher un historique de modifications à des utilisateurs authentifiés (par exemple un espace collaboratif où plusieurs rédacteurs suivent l’évolution d’un article avant publication), la route de révisions devient un vrai atout : elle évite de reconstruire un système de versionnage maison, puisque WordPress gère déjà nativement la création d’une révision à chaque enregistrement significatif du contenu.
add_filter( 'rest_prepare_revision', function( $response, $revision ) {
$response->data['resume'] = wp_trim_words( $revision->post_content, 20 );
return $response;
}, 10, 2 );Ce filtre ajoute un résumé court à chaque révision renvoyée, pratique pour afficher une liste compacte d’historique sans charger le contenu complet de chaque version.
Masquer complètement les révisions d’un type de contenu
À l’inverse, pour un type de contenu où l’historique n’a aucun sens éditorial (une fiche technique générée automatiquement, par exemple), il est possible de désactiver entièrement les révisions à la source, ce qui évite aussi d’alourdir la base de données :
add_filter( 'wp_revisions_to_keep', function( $nombre, $post ) {
if ( 'fiche_technique' === $post->post_type ) {
return 0;
}
return $nombre;
}, 10, 2 );Un contenu sans révision n’expose alors plus du tout la sous-route /revisions, celle-ci renvoyant simplement une liste vide.
Ce que cela change pour la donnée reçue côté front
Le choix d’exposer ou non les révisions influence directement la fraîcheur perçue de la donnée par un front qui interrogerait, par erreur, la mauvaise route. Un développeur qui construirait un aperçu de contenu en s’appuyant involontairement sur la dernière révision plutôt que sur la version publiée verrait apparaître des modifications non encore validées, ce qui a déjà causé des confusions sur des projets où l’équipe de prévisualisation manipulait les deux routes sans distinction claire entre elles.
En résumé
L’API REST de WordPress ne cache pas les révisions par accident : elle les protège par une capacité d’édition, tout en les rendant disponibles à qui en a l’usage légitime. Un projet headless gagne à trancher explicitement ce point dès sa conception, plutôt que de laisser un développeur découvrir, au détour d’un bug de prévisualisation, qu’une route de révisions existait sans que personne n’ait décidé consciemment de son rôle dans l’architecture du front.
