En tant que canaux essentiels par lesquels les composants logiciels interagissent et où les données circulent sur internet, les API sont le cœur des services web contemporains. Les technologies d'API comme SOAP (un protocole de messagerie pour services web), REST (un style architectural) et GraphQL (un langage de programmation et un outil) simplifient le développement logiciel en permettant l'intégration de données et de services tiers. Les API permettent également aux entreprises de proposer des fonctionnalités de service sécurisées et des échanges de données à leurs employés, partenaires commerciaux et utilisateurs.
Bien qu'il existe de nombreux types d'API, les débats sur deux paradigmes majeurs dominent ces dernières années : REST (« Representational State Transfer ») et GraphQL. Ces deux paradigmes offrent de nombreux avantages et sont couramment utilisés dans des projets de mise en réseau à travers le monde. Cependant, ils diffèrent considérablement dans leur gestion du trafic de données. Nous allons examiner ces différences et expliquer comment les entreprises peuvent tirer parti des API REST et GraphQL pour optimiser leurs réseaux.
Pour comparer les API REST et GraphQL, il est essentiel de bien comprendre ces deux technologies.
Développé au début des années 2000, REST est un style d’architecture structuré destiné aux applications hypermédias en réseau, conçu pour utiliser un protocole de communication de type client/serveur sans état pouvant être mis en cache. Les API REST, également appelées API RESTful, constituent le moteur des architectures REST.
Les API REST utilisent des identificateurs de ressources uniques (URI) pour accéder aux ressources. Elles fonctionnent via différents points de terminaison tqui réalisent des opérations CRUD (« créer », « lire », « mettre à jour » et « supprimer ») pour les ressources réseau. Les API REST s'appuient sur un format de données prédéfini, appelé type de média ou type MIME, qui détermine la structure et la taille des ressources fournies aux clients. Les formats les plus courants sont JSON et XML (et parfois HTML ou du texte brut).
Lorsqu'un client demande une ressource, le serveur traite la requête et renvoie toutes les données associées à cette ressource. La réponse comprend des codes de réponse HTTP comme « 200 OK » (pour les requêtes réussies) et « 404 Not Found » (pour des ressources inexistantes).
GraphQL est un langage de requête et un environnement d’exécution d’API que Facebook a développé en interne en 2012 avant qu’il ne devienne un projet open source en 2015.
GraphQL, quant à lui, est défini par des schémas d'API écrits dans un langage de définition de schéma spécifique à GraphQL. Chaque schéma spécifie les types de données que l'utilisateur peut interroger ou modifier, ainsi que les relations entre ces types. Chaque champ d'un schéma est pris en charge par un résolveur. Le résolveur transforme les requêtes, mutations et abonnements GraphQL en données, et récupère ces données depuis des bases de données, des services cloud ou d'autres sources. Les résolveurs spécifient également les formats de données et permettent d'assembler des données provenant de diverses sources.
Contrairement à REST, qui utilise généralement plusieurs points de terminaison pour récupérer des données et effectuer des opérations réseau, GraphQL expose les modèles de données via un point d'accès unique. Les clients envoient leurs requêtes GraphQL à ce point d'accès, peu importe les informations qu'ils recherchent. L'API accède ensuite aux propriétés des ressources et suit les références entre elles pour récupérer toutes les données nécessaires à partir d'une seule requête adressée au serveur GraphQL.
Les API GraphQL et REST sont conçues pour les échanges de données basés sur des ressources. Elles utilisent des méthodes HTTP (comme les requêtes PUT et GET) qui déterminent les opérations qu’un client peut effectuer. Il existe cependant des différences essentielles entre ces deux types de systèmes, qui expliquent non seulement la prolifération de GraphQL, mais aussi la pérennité des systèmes RESTful.
GraphQL ajoute de l’efficacité et de la flexibilité à REST. Les API GraphQL sont souvent considérées comme une mise à niveau des environnements RESTful, en particulier parce qu’elles facilitent la collaboration entre les équipes front-end et back-end. GraphQL constitue la prochaine étape logique dans l’évolution du paysage des API des organisations, car il permet de résoudre les problèmes souvent rencontrés avec REST.
Cependant, REST a longtemps été la norme en matière d'architectures API, et de nombreux développeurs et architectes continuent de s'appuyer sur des configurations RESTful pour gérer leurs réseaux informatiques. Il est donc essentiel pour les entreprises de bien comprendre les distinctions entre ces deux approches dans le cadre de leur stratégie de gestion des réseaux informatiques.
Les API REST et GraphQL diffèrent au niveau de la gestion :
REST repose sur plusieurs points de terminaison et des interactions sans état, où chaque requête API est traitée comme une nouvelle, sans lien avec les précédentes. Cela signifie que les clients reçoivent toutes les données associées à une ressource, même s'ils n'en ont besoin que d'une partie (ce qu'on appelle la sur-récupération). De plus, si les données recherchées s'étendent sur plusieurs ressources, un système REST oblige souvent le client à interroger chaque ressource séparément pour combler les lacunes de la première requête (ce qu'on appelle la sous-récupération). Les API GraphQL, quant à elles, utilisent un point de terminaison unique pour fournir aux clients une réponse précise et complète en une seule requête, éliminant ainsi les problèmes de sur- et sous-récupération.
Dans une architecture REST, les équipes doivent versionner les API pour modifier les structures de données et éviter les erreurs système et interruptions de service côté utilisateur final. En d’autres termes, les développeurs doivent créer un nouveau point de terminaison chaque fois qu’ils apportent des modifications, ce qui crée plusieurs versions de l’API et en complique potentiellement la maintenance. GraphQL réduit ce phénomène de versionnement, car les clients peuvent spécifier les données requises dans la requête. L’ajout de nouveaux champs au serveur n’affecte pas les clients qui n’en ont pas besoin. À l’inverse, si des champs sont obsolètes, les clients pourront continuer à les interroger jusqu’à la mise à jour des requêtes.
Les API REST devraient utiliser des codes d'état HTTP pour indiquer le statut ou la réussite d'une requête, chaque code ayant une signification spécifique. Une requête HTTP 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.
À première vue, cette approche semble simple, mais ces codes d'état sont souvent plus utiles aux utilisateurs qu'aux API elles-mêmes, notamment en cas d'erreurs. REST n'a pas de spécification claire pour les erreurs, ce qui peut rendre la détection des erreurs plus difficile, car elles peuvent apparaître comme des erreurs de transport ou ne pas être accompagnées d'un code spécifique. Cette situation oblige parfois le personnel à consulter la documentation pour comprendre la nature des erreurs et leur mode de communication dans l'infrastructure.
Avec les API GraphQL, toutes les requêtes, qu'elles aboutissent à une erreur ou non, renvoient un code 200 OK, car les erreurs ne sont pas communiquées via les codes HTTP (sauf pour les erreurs de transport). Le système inclut les erreurs directement dans le corps de la réponse, avec les données, ce qui oblige les clients à analyser les données retournées pour vérifier si la requête a été réussie.
Cela dit, GraphQL dispose d’une spécification pour les erreurs, de sorte que les erreurs d’API se distinguent plus facilement des erreurs de transport. La nature exacte des erreurs apparaît dans l’entrée « error » du corps de la réponse, ce qui peut être une bonne raison de privilégier les API GraphQL.
REST ne dispose pas d’une prise en charge intégrée des mises à jour en temps réel. Si une application a besoin de fonctionner en temps réel, 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, 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.
L'environnement 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.
Les API GraphQL sont plus récentes, mais l'écosystème GraphQL s'est considérablement développé depuis son introduction. Il existe désormais divers outils et bibliothèques disponibles pour le développement côté serveur et côté client. Des outils comme GraphiQL 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.
Les API REST, quant à elles, reposent sur des mécanismes comme les eTags et les en-têtes Last-Modified pour la mise en cache des appels d'API. Bien que ces stratégies soient efficaces, leur mise en œuvre peut être complexe et ne convient pas à tous les cas d'usage.
Les API GraphQL peuvent être plus difficiles à mettre en cache en raison de la nature dynamique des requêtes. Toutefois, le déploiement 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 faciliter les efforts de mise en cache plus larges dans les architectures GraphQL.
Ni les API REST ni les API GraphQL ne sont intrinsèquement supérieures. Ce sont des outils différents qui sont adaptés à des tâches différentes.
REST est généralement plus facile à mettre en œuvre et peut être une bonne option lorsqu’un protocole de communication simple et pouvant être mis en cache avec des contrôles d’accès stricts est préféré (pour les sites de commerce électronique destinés au public comme Shopify et GitHub, par exemple).
Cependant, compte tenu des risques d'extraction excessive ou insuffisante de données, les API REST sont particulièrement recommandées pour :
Les API GraphQL permettent une récupération de données plus flexible et plus efficace, ce qui peut améliorer les performances du système et la facilité d’utilisation pour les développeurs. Ces fonctionnalités font de GraphQL une option particulièrement utile pour créer des API dans des environnements complexes dont les exigences front-end évoluent rapidement. Notamment :
Bien qu'ils adoptent des approches différentes, REST et GraphQL ont tous deux le potentiel d'améliorer considérablement l'évolutivité du réseau et les performances des serveurs.
Que vous choisissiez de déployer des API REST, GraphQL ou une combinaison des deux, votre entreprise peut bénéficier d'une vaste gamme d'applications potentielles, y compris des implémentations dans divers langages de programmation (comme JavaScript) et l'intégration avec des architectures microservices et sans serveur.Avec IBM API Connect, vous pouvez exploiter ces deux types d'API pour optimiser votre infrastructure informatique.
IBM API Connect est une solution de gestion complète du cycle de vie des API, qui vous aide à créer, gérer, sécuriser, promouvoir et monétiser vos API tout en facilitant la transformation numérique dans les centres de données et les environnements cloud. Cela permet aux entreprises et à leurs clients de dynamiser les applications numériques et de stimuler l'innovation en temps réel.
Avec API Connect, les entreprises peuvent s'assurer qu'elles sont à la pointe de la gestion des API, ce qui sera inestimable dans un paysage informatique qui continuera à croître, à se complexifier et à devenir de plus en plus compétitif au fil du temps.
Explorer IBM API Connect
S’abonner aux actualités concernant l’IA