GraphQL vs REST : comment s’y retrouver

REST : comment ça marche

L’élément central derrière REST est la ressource. Une API REST comprend un endpoint différent pour chaque ressource, avec des méthodes de requêtage HTTP différentes. Prenons exemple sur l’API d’un blog, avec 2 ressources, l’une pour les auteurs, l’autre pour les articles. L’endpoint pour chaque ressource peut suivre le pattern suivant :

METHOD /api/:resource:/:id:

Ce que cela signifie : afin de parcourir une liste de chaque article, il vous faut passer une requête GET, comme montre la commande ci-dessous :

GET /api/articles

Si vous souhaitez requêter chaque article, vous devez ajouter la ressource ID à l’endpoint :

GET /api/articles/1

Si, ainsi, les API REST peuvent devenir très verbeuses, les opérations standard (create, read, update, delete - CRUD) peuvent être intuitivement effectuées pour chaque ressource. Avec REST, pour mettre à jour une ressource, vous utilisez la méthode PATCH au lieu de GET. Pour écrire une ressource, on utilise POST, et la supprimer DELETE.

La facilité d’usage et sa structure intuitive ont largement contribué à la popularité de REST. Mais  popularité ne rime pas forcément avec pertinence. Toutes les applications ne nécessitent pas le recours à une structure CRUD, et certaines opérations qui impliquent de grands jeux de données peuvent rompre avec l’aspect structuré de REST.

GraphQL : une alternative

Comparé à REST, et son modèle très structuré basé sur les ressources, GraphQL apparait comme un langage de requête plus flexible, au-dessus d’une API. Cela permet d’interagir avec une API de façon plus « programmatique ». Github s’est récemment converti à ce format.

Si l’on reprend l’exemple du blog, dans un contexte GraphQL, chaque requête peut être effectuée sur un endpoint, les actions et les données étant définies dans la requête  en elle-même :

GET /api?query={ article(id:"1") { title, content } }

Cette requête commande à l’API de lister un article ayant pour ID 1 et de retourner son titre et son contenu. Le même endpoint peut aussi être utilisé pour effectuer des actions au sein de l’API. Celles-ci sont alors appelées mutations. Ce sont des méthodes pré-définies qui peuvent être appelées par le client :

POST /api?mutation={ updateArticle(id: "1", title: "new title") { title, content } }

GraphQL VS REST : le choix de GraphQL

GraphQL est un bon choix architectural si l’application et sa structure de donnée font appel à de nombreuses requêtes. Dans notre exemple du blog, si vous souhaitez requêter un article  pour obtenir l’auteur, les tags et les commentaires, il vous faut au minimum 4 requêtes distinctes. Avec GraphQL, cela peut être effectué de façon plus programmatique, et permettre au client de requêter les seules informations souhaitées au final.

GraphQL est également un bon moyen pour minimiser les modifications liées à la montée de version – ce qui arrive quand les ressources et les schémas de données changent dans  une API REST. En interrogeant précisément les bonnes informations, chaque nouvel élément n’interférera pas avec l’implémentation en place. Si votre jeu de données s’agrandit et si vous devez optimiser vos schémas, GraphQL dissimulera cette complexité et permettra au client d’interagir avec les nouvelles données d’une façon plus cohérente.

GraphQL VS REST : le choix de REST

D’un autre côté, le plus gros avantage de REST sur GraphQL est la facilité avec laquelle les données peuvent être « cachées » et la transparence des actions effectuées sur l’API. En reprenant l’exemple du blog, lorsqu’on interroge l’article x, la requête est cohérente pour tous les clients. Les données ainsi retournées peuvent être placées dans le cache côté serveur pour d’autres requêtes, et réduire ainsi les opérations de la base  pour accélérer les temps de réponse de l’API.

REST est également le bon choix si l’on doit composer avec des données très structurées, là où les actions effectuées sur les API suivent un pattern prévisible – sur un mode CRUD.

REST et GraphQL ont tous deux leurs propres avantages. Mais au-delà de la scalabilité et de la technologie, il convient de prendre en compte le mode de consommation de l’API. Bien comprendre son marché devient alors clé. Une application traditionnelle CRUD sera mieux servie par une API REST, mais si vous développez un outil interne pour des équipes déjà expérimentées sur GraphQL, ce dernier peut être le bon choix pour maintenir la productivité et réduire toute éventuelle friction – l’inverse est vrai pour REST.