Qu'est-ce que GraphQL ?
Découvrir le développement d’API avec IBM API Connect Découvrez comment IBM CIO a réduit ses coûts d'API
Illustration de l’API et du workflow

Publication : 8 décembre 2023
Contributeurs : Chrystal R. China, Michael Goodwin

Qu'est-ce que GraphQL ?

GraphQL est un langage de requête open source et un runtime côté serveur qui spécifie comment les clients doivent interagir avec les interfaces de programmation des applications (API). 

Grâce à une syntaxe intuitive qui permet aux utilisateurs de faire des requêtes API en une seule ligne ou en quelques lignes (au lieu de devoir accéder à des points de terminaison complexes bourrés de paramètres), les technologies GraphQL facilitent la génération des requêtes API et la réponse à ces dernières. GraphQL est un niveau au-dessus des architectures RESTful traditionnelles.

Au début des années 2010, Facebook connaît une croissance et une transformation massives. La croissance de sa base d’utilisateurs et un environnement d’application mobile de plus en plus complexe sont autant de facteurs qui commençaient à peser sur son approche RESTful existante, qui nécessitait de multiples allers-retours vers différents points de terminaison pour récupérer toutes les données de requête nécessaires. 

Les API REST (Representational State Transfer) (REST) et RESTful n’étaient pas équipées pour gérer des interfaces utilisateur complexes basées sur les données, et elles rencontraient souvent des problèmes de latence et d’inefficacité au niveau des données, en particulier pour les utilisateurs mobiles ayant des forfaits de données limités et/ou coûteux.

Face à ces difficultés, les ingénieurs de Facebook développent GraphQL (ainsi que la plateforme d’applications à page unique React), et le publient sous forme de solution open source en 2015. En 2018, Facebook finit par transférer le service à la GraphQL Foundation, qui comprend des sociétés membres comme AWS, Gatsby, Intuit et IBM.  

Exploitez vos données avec GraphQL et IBM API Connect

Découvrez comment éliminer les silos de données tout en écrivant moins de code grâce à des API GraphQL hautement réactives.

Contenu connexe

IBM API Connect remporte les plus hautes distinctions

Comment fonctionnent les API GraphQL ?

Les entités déclaratives de récupération des données d’une architecture GraphQL s’articulent autour de plusieurs composants et processus clés, chacun jouant un rôle unique dans la gestion et le traitement des données.

Elles comprennent :

Schémas

GraphQL s’appuie sur un puissant système de types où tous les types de données sont enregistrés dans le langage de définition de schéma (SDL) de GraphQL. Les schémas typés indiquent les types de données qui peuvent faire l’objet d’une requête dans l’API, ainsi que les relations entre les types et les opérations disponibles pour l’utilisateur. En d’autres termes, ils définissent les capacités de l’API et la forme des données avec lesquelles les clients peuvent interagir.

Résolveurs

Chaque champ d’un schéma est soutenu par un résolveur qui remplit les données et détermine la réponse à un ensemble de champs. Les résolveurs, qui peuvent récupérer des données à partir d’une base de données, d’un service cloud ou de toute autre source ou presque, fournissent des instructions pour transformer une opération GraphQL (par exemple, une requête, une mutation ou un abonnement) en données.

Lorsqu’un champ de requête est exécuté, le système génère un appel vers le résolveur correspondant pour produire la valeur suivante. Si un champ produit une valeur scalaire (par exemple, une chaîne ou un nombre), l’exécution se termine. Si un champ génère une valeur d’objet, la requête contiendra plus de champs pour cet objet. Ce processus se poursuit jusqu’à ce qu’il ne reste que des champs scalaires.

Les résolveurs facilitent également le formatage des données et permettent au système de regrouper les informations provenant de diverses sources de données.

Requêtes

Une requête de données est la requête faite par le client au serveur GraphQL. Elle spécifie les données que le client souhaite récupérer. Lorsqu’une requête arrive, GraphQL la compare aux définitions du schéma et, si la requête est valide, il l’exécute. La structure d’une requête reflète généralement la structure des données de réponse : les exigences en matière de données sont donc explicites et prévisibles.

Mutations

Les mutations sont des opérations GraphQL qui créent, mettent à jour ou suppriment des données sur le serveur. Elles sont similaires aux opérations POST, PUT, PATCH et DELETE des API RESTful.

Comme dans le cas d’une requête, les mutations GraphQL sont comparées au schéma et à ses définitions pour être validées. Une fois la mutation validée et exécutée, le serveur renvoie une réponse JSON.

GraphQL et API REST 

Bien que les API GraphQL soient devenues une alternative plus efficace et plus flexible, REST et RESTful ont longtemps été la norme pour les architectures API. Une API REST est un style d’architecture structuré pour les applications hypermédias en réseau, conçu pour utiliser un protocole de communication de type client-serveur sans état (généralement HTTP) pouvant être mis en cache.

GraphQL et REST permettent tous deux aux clients de communiquer avec les serveurs et les données de requête, mais certaines différences clés expliquent la prolifération des systèmes GraphQL. 

Récupération des données

Les API REST sont conçues autour de ressources (par exemple, tout type d’objet, de données ou de service accessible au client), et elles fonctionnent en ayant des points de terminaison différents (URL) pour chaque ressource. Elles utilisent une structure de données fixe pour déterminer la forme et la taille des ressources fournies aux clients.

Lorsque le client demande une ressource, le serveur envoie toutes les données qui lui sont associées. Si un client a uniquement besoin d’un sous-ensemble de données, il reçoit quand même toutes les données (sur-récupération). Si le client a besoin de données couvrant plusieurs ressources, il devra souvent effectuer plusieurs appels d’API à cause de la récupération inadéquate exécutée à la suite de la requête initiale (sous-récupération). 

GraphQL, en revanche, utilise un seul point de terminaison qui fournit une description complète et compréhensible des données.  Les requêtes GraphQL peuvent accéder aux propriétés des ressources et suivre les références entre ces dernières. Le client peut ainsi obtenir toutes les données dont il a besoin à partir d’une seule requête au serveur GraphQL et éviter les problèmes de sur-récupération et de sous-récupération.

Gestion des versions

Dans une architecture REST, changer la structure des données demande souvent aux équipes de mettre à jour la version de l’API pour éviter les erreurs système et les interruptions de service pour l’utilisateur final. Cela signifie que les développeurs doivent créer un nouveau point de terminaison à chaque modification de la structure, ce qui crée plusieurs versions de l’API et complique le processus de maintenance. 

GraphQL élimine ce processus de versionnement, car les clients peuvent spécifier leurs demandes dans la requête. Si de nouveaux champs sont ajoutés au serveur, les clients qui n’en ont pas besoin ne seront pas affectés. Inversement, si des champs sont obsolètes, les clients pourront continuer à les interroger jusqu’à la mise à jour de leurs requêtes. 

Gestion des erreurs

Les API REST utilisent des codes d’état HTTP pour indiquer le statut/la réussite d’une requête. Chaque code d’état a une signification spécifique. Une requête réussie renvoie le code d’état 200, tandis qu’une erreur client peut renvoyer le code d’état 400 et une erreur de serveur le code d’état 500.

GraphQL gère les erreurs différemment. Chaque requête, qu’elle ait entraîné une erreur ou non, renvoie un code d’état OK 200. Les erreurs ne sont pas communiquées à l’aide de codes d’état HTTP : le système communique les erreurs dans le corps de la réponse avec les données. Cette approche exige que les clients analysent le corps de la réponse pour déterminer si la requête a été exécutée avec succès, ce qui peut rendre le débogage des API GraphQL un peu difficile. 

Données en temps réel

REST ne dispose pas d’une prise en charge intégrée des mises à jour en temps réel. Si une application web ou mobile a besoin de fonctionner en temps réel avec une API REST, les développeurs doivent généralement mettre en œuvre des techniques telles que l’interrogation longue (où le client interroge le serveur de manière répétée à la recherche de nouvelles données), les server-sent events et les WebSockets, qui peuvent ajouter un niveau de complexité à l’application. 

En revanche, GraphQL inclut une prise en charge intégrée des mises à jour en temps réel via des abonnements. Les abonnements maintiennent une connexion stable au serveur, permettant au serveur d’envoyer des mises à jour au client chaque fois que des événements spécifiques se produisent et aux clients de maintenir des données API pertinentes. 

Outils et écosystème

L’écosystème REST est bien établi. Il met à la disposition des développeurs un large éventail d’outils, de bibliothèques et de frameworks. Cependant, l’utilisation d’API REST exige souvent des équipes qu’elles basculent entre plusieurs points de terminaison et qu’elles comprennent les conventions/schémas uniques de chaque API.

GraphQL est relativement nouveau, mais l’écosystème GraphQL s’est considérablement développé depuis son lancement : divers outils et bibliothèques sont désormais disponibles pour le développement de services front-end et back-end. Des outils comme GraphiQL, Apollo Studio et GraphQL Playground offrent de puissants environnements de développement intégrés (IDE), directement dans le navigateur, qui permettent d’explorer et de tester les API GraphQL. En outre, GraphQL prend efficacement en charge la génération de code, ce qui peut simplifier le développement côté client. 

Mise en cache

Les API REST s’appuient sur des mécanismes de mise en cache HTTP comme les ETags et les en-têtes Last-Modified. Bien qu’efficaces, les stratégies de mise en cache peuvent être complexes à mettre en œuvre et ne pas optimiser systématiquement les performances pour tous les cas d’utilisation.

Les API GraphQL peuvent être plus difficiles à mettre en cache en raison de la nature dynamique des requêtes. Toutefois, l’utilisation de requêtes persistantes, de la mise en cache des réponses et de la mise en cache côté serveur peut réduire ces difficultés et représenter des stratégies de mise en cache efficaces pour les architectures GraphQL. 

L’avenir de GraphQL 

Depuis la transition de GraphQL vers la GraphQL Foundation, les développeurs ont créé des implémentations pour divers langages de programmation, notamment JavaScript, Python, Ruby et PHP, entre autres. De plus, les API GraphQL ont été adoptées par de nombreuses entreprises, comme Github, Pinterest, Paypal, Shopify, Airbnb et d’autres1, permettant à davantage de clients de rationaliser les spécifications de données, de réduire la transmission de données réseau excessive ou inadéquate, et d’améliorer les capacités globales de récupération des données.

De plus, les entreprises et les développeurs militent en faveur d’une fédération ouverte des architectures GraphQL. Dans son itération actuelle, la fédération GraphQL utilise des services GraphQL distincts et les agrège en une seule API GraphQL, qui sert de point d’entrée à toutes les données back-end sous-jacentes et facilite la récupération de données via requête unique. Malheureusement, l’implémentation de la fédération est réservée à un fournisseur unique.

En réponse à cela, IBM défend la fédération démocratisée, qui facilite l’agrégation de données à partir des API GraphQL et non GraphQL, sans se limiter à une agrégation exclusive à GraphQL.2

Solutions connexes
IBM API Connect

IBM API Connect est une solution de gestion complète du cycle de vie des API qui permet de créer, de gérer et de sécuriser les API de manière cohérente, de les rendre plus accessibles et de les monétiser, contribuant ainsi à alimenter la transformation numérique des API hébergées localement et dans différents clouds. 

Explorer API Connect

API Development avec IBM API Connect

IBM API Connect facilite la création et le déploiement d’une API GraphQL de niveau production en quelques minutes. Il vous suffit de fournir les détails de connexion de votre source de données et une API GraphQL sécurisée et optimisée sera instantanément générée.

Découvrir le développement d’API avec API Connect
Ressources GraphQL et REST : quelle est la meilleure solution pour les API ?

Découvrez les approches distinctes adoptées par ces frameworks pour la création d’API, ainsi que leurs points forts et leurs points faibles.

IBM nommé leader dans le rapport Gartner dans la catégorie API Management

Lisez le rapport Magic Quadrant 2023 de Gartner sur la gestion des API pour découvrir pourquoi IBM continue d’être reconnu comme un leader dans ce domaine.

Développement de vos API et applications

Découvrez les outils IBM API Connect.

Aperçu IBM API Connect

Maximisez la valeur des API pour stimuler votre activité numérique avec une solution complète de gestion des API.

Capacités critiques pour la gestion des API

IBM nommé leader dans le rapport Gartner Critical 2023: Critical Capabilities for API Management.

Tutoriels sur IBM API Connect

Ces tutoriels fournissent des instructions pratiques qui aident les développeurs à apprendre à utiliser les technologies dans leurs projets.

Passez à l’étape suivante

Utilisez IBM API Connect pour sécuriser et gérer les API d’entreprise tout au long de leur cycle de vie. Cette solution vous aide, ainsi que vos clients, à créer, gérer, sécuriser, socialiser et monétiser les API d’entreprise. Elle est également disponible en tant que plateforme de gestion des API hautement évolutive sur IBM Marketplace et AWS.

Explorer API Connect Réserver une démo live
Passez à l’étape suivante

Prenez le contrôle de votre écosystème d’API tout en propulsant votre stratégie API.

Explorer IBM API Connect Demander une démo en direct
Notes de bas de page

1’ IBM acquires GraphQL startup StepZen to step up its game in API management » (lien externe à ibm.com), TechCrunch, 8 février 2023

2« Why GraphQL Needs an Open Federation Approach » (lien externe à ibm.com), The New Stack, 16 novembre 2023