Avec une API REST classique, récupérer un article et le nom de son auteur demande souvent deux appels successifs (l’un vers /posts/42, l’autre vers /users/7), ou un endpoint sur mesure qui les combine. GraphQL renverse la logique : le client envoie une seule requête décrivant précisément l’arborescence de champs qu’il veut, et le serveur répond avec exactement cette forme, ni plus ni moins.
GraphQL et WordPress
WordPress n’expose pas GraphQL nativement : son API native est REST. Pour en bénéficier, il faut une extension comme WPGraphQL, qui construit un schéma GraphQL à partir des types de contenus, taxonomies et champs personnalisés du site, exposé sur un point de terminaison unique, en général /graphql. C’est un choix fréquent dans les architectures « headless » où un front (Next.js, Nuxt…) consomme le contenu WordPress.
Exemple
query {
post(id: "42", idType: DATABASE_ID) {
title
author { node { name } }
}
}À ne pas confondre avec
- Une base de données graphe : GraphQL est un langage de requête pour API, il ne présuppose aucune structure de stockage particulière côté serveur.
- REST, dont il n’est pas un remplacement universel : REST reste plus simple à mettre en cache via HTTP standard, GraphQL brille surtout quand les besoins du client varient beaucoup d’une page à l’autre.
- Le sur-appel («overfetching») propre à certaines API REST, que GraphQL cherche justement à éviter en laissant le client choisir les champs, au prix d’une requête plus complexe à écrire côté client.
- Un point de terminaison GraphQL mal protégé peut autoriser des requêtes très coûteuses en une seule fois (imbrications profondes) : il est courant de limiter la profondeur ou la complexité autorisée des requêtes.