# « Il faut toujours GraphQL en headless » : quand une route REST simple suffit

> WPGraphQL apporte une réelle souplesse, mais son adoption systématique ajoute parfois de la complexité sans bénéfice mesurable face à un endpoint REST ciblé.

- Auteur : WordPress Développement
- Publié le : 2024-05-15
- Mis à jour le : 2024-05-15
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/toujours-graphql-headless-route-rest-simple-suffit/

## L’essentiel

- WPGraphQL résout un vrai problème de sur-récupération de données
- Un besoin figé et simple ne bénéficie pas toujours de cette souplesse
- La complexité d'exploitation de GraphQL a un coût d'équipe réel

« GraphQL, c'est ce qu'il faut utiliser pour tout projet headless sérieux. » Cette recommandation, souvent formulée sans nuance en début de projet, mérite d'être questionnée à la lumière de cas concrets où son adoption n'a apporté aucun bénéfice mesurable, tout en ajoutant une complexité d'exploitation dont l'équipe se serait bien passée.

WPGraphQL résout un problème réel et bien identifié : la sur-récupération de données inhérente à une API REST classique, qui retourne systématiquement l'intégralité des champs d'une ressource même quand le front n'en consomme qu'une poignée. Ce problème est réel sur un schéma riche et fortement imbriqué. Il l'est beaucoup moins sur un besoin figé, simple, et connu à l'avance.

## Le cas observé : une page d'accueil avec trois blocs fixes

Un projet met en place WPGraphQL pour alimenter une page d'accueil composée de trois sections fixes : un bloc d'articles récents, un bloc de témoignages, un bloc de chiffres clés. Aucune de ces sections n'évolue en structure au fil du temps, et aucun autre client que ce front unique ne consomme cette donnée. Le schéma GraphQL mis en place pour ce besoin représente, une fois maintenu dans la durée, davantage de code et de surface de test qu'une route REST personnalisée n'en aurait exigé pour le même résultat.

## Ce que la route REST équivalente aurait suffi à couvrir

```
register_rest_route( 'accueil/v1', '/composition', array(
    'methods'             => 'GET',
    'callback'            => function () {
        return array(
            'articles_recents' => accueil_get_articles_recents(),
            'temoignages'       => accueil_get_temoignages(),
            'chiffres_cles'     => accueil_get_chiffres_cles(),
        );
    },
    'permission_callback' => '__return_true',
) );
```

Cette route unique retourne exactement la donnée nécessaire, dans le format attendu par le front, sans nécessiter de schéma GraphQL, de résolveurs personnalisés, ni de bibliothèque cliente dédiée à l'interprétation des requêtes GraphQL. Le nombre de lignes de code à maintenir, sur ce cas précis, s'en trouve significativement réduit.

> L'essentiel à retenir : WPGraphQL résout un vrai problème de sur-récupération de données ; Un besoin figé et simple ne bénéficie pas toujours de cette souplesse ; La complexité d'exploitation de GraphQL a un coût d'équipe réel

## Où la balance penche réellement vers GraphQL

La souplesse de GraphQL redevient déterminante dès qu'un même schéma doit servir plusieurs clients aux besoins différents — un site web et une application mobile, par exemple — ou quand la structure du contenu évolue fréquemment, avec des combinaisons de champs imprévisibles à l'avance. Dans ce contexte, la capacité du client à préciser exactement les champs souhaités évite de multiplier les routes REST spécialisées à chaque nouveau besoin.

### Le coût d'équipe, souvent sous-estimé

Adopter GraphQL implique une compétence supplémentaire à maintenir dans l'équipe : compréhension du langage de requête, gestion de la complexité et de la profondeur des requêtes, surveillance des performances des résolveurs. Sur une petite équipe qui maîtrise déjà bien l'API REST native, ce coût d'apprentissage doit être mis en balance avec le bénéfice réel attendu, pas simplement accepté par principe.

| Contexte | Choix pertinent |
| --- | --- |
| Besoin figé, un seul client consommateur | Route REST personnalisée |
| Plusieurs clients aux besoins de champs différents | WPGraphQL |
| Contenu très imbriqué et évolutif | WPGraphQL |
| Équipe sans expérience GraphQL, délai court | Route REST personnalisée |

- Identifier le nombre réel de clients distincts qui consommeront le même contenu, pas seulement au lancement.
- Évaluer la stabilité attendue de la structure du contenu avant de choisir la souplesse de GraphQL par défaut.
- Chiffrer honnêtement le coût de montée en compétence de l'équipe sur GraphQL si elle n'y est pas déjà exposée.

> Une technologie choisie pour sa réputation de modernité, plutôt que pour le problème précis qu'elle résout, ajoute presque toujours plus de complexité qu'elle n'en retire.

## En résumé

WPGraphQL apporte une réponse pertinente à un problème réel de sur-récupération de données sur des schémas riches et évolutifs. Il ne constitue pas pour autant un choix par défaut justifié dans tous les contextes : un besoin simple, figé et consommé par un seul client trouve souvent une réponse plus légère à maintenir dans une route REST personnalisée, sans que cela ne traduise un renoncement à la modernité du projet.