« REST » (Representational State Transfer) n’est pas une technologie mais un style d’architecture : chaque ressource (un article, un utilisateur, un produit) a sa propre adresse, et on agit dessus avec le verbe HTTP adapté plutôt qu’avec une fonction dédiée par action. Une API construite ainsi reste prévisible : si on connaît l’URL d’un article, on devine celle de la liste des articles.
L’API REST de WordPress
Depuis la version 4.7, WordPress embarque nativement une API REST accessible sous /wp-json/. Elle expose articles, pages, médias, utilisateurs et taxonomies, et sert de base à l’éditeur de blocs lui-même, qui l’utilise en coulisses pour enregistrer chaque modification. On peut l’étendre avec register_rest_route() pour exposer ses propres données, par exemple depuis une extension métier.
Exemple
GET https://exemple.fr/wp-json/wp/v2/posts?per_page=5
Réponse (extrait) :
[
{ "id": 42, "title": { "rendered": "Bonjour" } }
]Pièges fréquents
- Confondre REST et JSON : REST est le style d’architecture, JSON n’est qu’un format de réponse parmi d’autres (XML reste possible, plus rarement utilisé aujourd’hui).
- Oublier l’authentification pour les routes d’écriture : un
POSTvers/wp-json/wp/v2/postsexige un jeton ou des cookies valides, sinon WordPress répond 401. - Exposer par erreur des champs sensibles (adresse e-mail d’un auteur, par exemple) faute d’avoir vérifié les permissions dans
register_rest_route(). - Négliger la pagination sur une collection volumineuse : sans le paramètre
per_page, l’API renvoie un nombre d’éléments limité par défaut (dix en général) et non l’intégralité des résultats.