# « Les révisions de contenu, exposées ou non par l’API REST en headless »

> Que renvoie réellement l'API REST sur les révisions d'un article, et pourquoi les masquer change la donnée reçue par un front éditorial.

- Auteur : Clément Hadrot
- Publié le : 2025-12-27
- Mis à jour le : 2025-12-27
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/revisions-contenu-exposees-api-rest-headless/

## L’essentiel

- Route dédiée /revisions, non exposée par défaut
- Nécessite une authentification et une capacité
- Utile pour un historique éditorial côté front

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.

> L'essentiel à retenir : Route dédiée /revisions, non exposée par défaut ; Nécessite une authentification et une capacité ; Utile pour un historique éditorial côté front

## 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.