Depuis la version 4.7, chaque site WordPress répond nativement à des requêtes HTTP structurées, sans qu’aucune extension ne soit nécessaire pour lire ou modifier son contenu depuis l’extérieur. C’est cette couche, souvent invisible pour un simple visiteur, qui fait tourner l’éditeur de blocs en coulisses.
Requêter le contenu
Une simple requête GET vers l’URL /wp-json/wp/v2/posts renvoie la liste des derniers articles publiés au format JSON. Chaque type de contenu public (articles, pages, médias, types personnalisés déclarés avec show_in_rest) dispose ainsi de son propre point de terminaison.
curl https://exemple.fr/wp-json/wp/v2/posts?per_page=5Pour créer ou modifier une ressource, il faut s’authentifier (par exemple avec un mot de passe d’application) et envoyer une requête POST ou PUT avec un jeton dans l’en-tête Authorization.
Étendre l’API
Une extension peut ajouter ses propres routes avec register_rest_route(), ou exposer un champ personnalisé sur une route existante avec register_rest_field(). C’est également cette API que Gutenberg utilise pour sauvegarder les articles sans recharger la page.
Pièges fréquents
- Un point de terminaison public expose par défaut les données sans authentification : il faut penser aux permissions (
permission_callback) dès la déclaration de la route. - Certains hébergeurs ou pare-feux bloquent par erreur les requêtes vers
/wp-json/, ce qui casse silencieusement l’éditeur. - Les réponses peuvent être filtrées à l’aide du paramètre
_fields, qui limite les propriétés renvoyées et réduit le poids de la réponse quand seules quelques informations sont nécessaires côté client.
Documentation officielle : REST API Handbook.