GraphQL : une approche API pas en REST

De nos jours, REST (Representational State Transfer) est le standard le plus utilisé quand il s’agit de mettre en place une API (Application Programming Interface). Néanmoins une nouvelle approche a le vent en poupe : il s’agit de GraphQL, un nouveau format qui est venu pour remédier à certaines limites de REST.

De nos jours, REST (Representational State Transfer) est le standard le plus utilisé quand il s’agit de mettre en place une API (Application Programming Interface). Néanmoins une nouvelle approche a le vent en poupe : il s’agit de GraphQL, un nouveau format qui est venu pour remédier à certaines limites de REST. 

REST, une valeur sûre

Si REST est la référence pour l’élaboration d’une API, c’est grâce à sa simplicité en termes de manipulation des données. Chaque entité exposée dans REST est une ressource qui peut être demandée avec des requêtes HTTP. Si nous prenons l’exemple d’une API qui fournit des articles, avec REST vous pourriez effectuer les opérations suivantes : 

GET /api/articles    

Cette requête HTTP permet d’obtenir la liste des articles disponibles. Vous pourriez aussi récupérer un article en particulier, en ajoutant son identifiant par exemple : 

GET /api/articles/166   

D’autres opérations peuvent être effectuées, notamment pour créer, mettre à jour ou supprimer un article. Ces opérations standards sont souvent appelées CRUD (Create, Read, Update, Delete). Chaque opération effectuée dans REST passe par un EndPoint (point d’entrée), qui n’est rien d’autre que l’URLS de la requête HTTP, donnée dans les exemples ci-dessus. Et si par exemple, vous souhaitez récupérer les commentaires associés à un article, il faudra faire les mêmes opérations avec d’autres points d’entrées : 

GET /api/comments 

DELETE /api/comments/42   

Autant dire, que pour un système d’information, dans lequel beaucoup de données transitent, le nombre de points d’entrées et des ressources à exploiter peuvent vite devenir problématique.  L’autre inconvénient de REST réside dans le fait d’exposer une ressource avec toutes les données qui lui sont associées. Ceci est sans doute inutile car toutes ces informations ne seront pas forcément exploitées.
 

GraphQL à la rescousse

GraphQL (QL pour Query Language) est un langage de requête pour les API. Il propose une approche totalement différente des API REST. Développé et utilisé en production par Facebook en 2012, il est ouvert au grand public en 2015. Depuis d’autres sociétés, dont GitHub, se sont lancées dans l’aventure.  Contrairement à REST, GraphQL permet de centraliser les requêtes dans un seul point d’entrée, les opérations à effectuer sont passées dans la requête elle-même. 

Comme on peut le voir ci-dessous, GraphQL utilise uniquement deux opérations (query et mutation) pour consulter ou mettre à jour les données. 

GET /api?query={ article(id:"166") { title, content } }  POST /api?mutation={ updateArticle(id: "43", title: "new title") { title, content } } 

Dans ces deux exemples, l’API GraphQL permet de récupérer un article (operation query), avec uniquement les informations spécifiées dans la requête (title, content). La volumétrie d’informations qui transite est ainsi optimisée.  Si nous revenons à notre exemple des commentaires, GraphQL permet aussi de faire des requêtes imbriquées pour obtenir d’un seul coup l’article et les commentaires qui lui sont associés.  GraphQL est venu résoudre d’autre lacunes de REST, et notamment : 

  • Un typage fort des données, c’est à dire que vous pouvez savoir avec exactitude la nature des paramètres en entrée et des données en sortie (entier, texte…). 
  • Une documentation automatique qui reflète la structure des données qu’il est possible d’obtenir.  

Mais tout n’est pas encore parfait, car contrairement à REST l’un des principaux inconvénients de GraphQL est la gestion du cache. Comme les requêtes sont spécifiques, il est difficile de mutualiser le cache et de servir la même réponse.    
 

En résumé 

GraphQL n’a pas vocation à concurrencer REST, il suffit de voir l’exemple de GitHub qui l’utilise en supplément de son API REST. Il vient comme une alternative intéressante pour mieux cibler sa demande et alléger la volumétrie d’informations qui peut transiter entre un système client/serveur.  Pour montrer sa popularité grandissante, la plupart des technos et des frameworks du marché propose une implémentation de GraphQL.Mais REST a encore un bon avenir, car sa simplicité et sa mutualisation de cache en font une valeur sûre.