DigitalCorner

Les nouvelles technologies vues par les consultants Wavestone

Comparaison entre les API REST et GraphQL

Comparaison entre les API REST et GraphQL

Il est indéniable que toute entreprise souhaitant exceller dans son domaine se doit de rester à la pointe de l’innovation. C’est le cas notamment des clients de Wavestone, qui s’efforcent d’améliorer leurs systèmes d’information en utilisant diverses technologies, nouvelles ou non, dans le but d’optimiser leurs processus, accroître leur efficacité et offrir de meilleurs services à leurs utilisateurs.

Parmi les technologies utilisées dans ce sens, on peut citer les API (Application Programming Interface). Les API sont essentielles pour connecter et intégrer les systèmes informatiques. Elles facilitent le développement de logiciels et augmentent l’agilité des entreprises, leur permettant de s’adapter rapidement aux changements du marché et aux besoins des utilisateurs.

Deux paradigmes de ce domaine vont être étudiées : les API REST, bien établies et familières, et les API GraphQL, plus récentes mais prometteuses. Pour les consultants en transformation digitale, comprendre les forces et les faiblesses de chaque approche est crucial pour choisir la solution la mieux adaptée aux besoins spécifiques de leurs clients.

Cet article se propose de comparer les API REST et GraphQL en termes de structure, performance, flexibilité et cas d’utilisation, afin de vous fournir les connaissances nécessaires pour faire un choix éclairé dans vos projets de transformation digitale.

Tout d’abord, qu’est-ce qu’une API ?

API est un acronyme qui signifie Application Programming Interface (ou Interface de Programmation d’Applications). Ce n’est rien d’autre qu’une interface logicielle permettant de connecter deux logiciels ou services afin qu’ils puissent communiquer et ainsi partager des données ou des fonctionnalités de manière sécurisée et contrôlée.

Par exemple, lorsqu’un utilisateur réserve une course sur l’application de VTC Uber, l’application fait appel à d’autres services fournis par des applications tierces via leurs API :

  • Lorsque l’utilisateur renseigne l’adresse où il souhaite se rendre, Uber fait appel au service de localisation et de carte fourni via l’API de Google Maps pour calculer l’itinéraire le plus optimisé en termes de temps entre sa position actuelle et sa destination ;
  • Ensuite, une fois le trajet effectué, Uber fait appel à un système de paiement fourni via différentes API (ApplePay, PayPal, etc.) selon le choix de l’utilisateur afin de facturer la course.

La Figure 1 suivante illustre l’exemple ci-dessus :

Figure 1 – Illustration de l’exemple Uber

On voit donc que les développeurs peuvent s’appuyer sur des API pour capitaliser sur les fonctionnalités existantes au lieu de repartir de zéro. L’approche « API-First » devient d’ailleurs de plus en plus en vogue parmi les clients de Wavestone. C’est une stratégie de développement logiciel où la conception et le développement d’API est une priorité. En effet, les API deviennent aujourd’hui des produits en soit et ne sont plus considérées comme de simples éléments d’intégration.

Comprendre les API REST

REST ou Representational State Transfer est un style architectural pour la conception de services web. Il repose sur un ensemble de contraintes et de principes qui facilitent la communication entre les applications. REST a été introduit par Roy Fielding, un informaticien américain, dans sa thèse de doctorat en 2000. Cette technologie d’API est rapidement devenue la norme pour les API web en raison de sa simplicité et de son efficacité, offrant une approche standardisée pour l’interaction entre les clients et les serveurs.

Principes fondamentaux :

Statelessness

Chaque requête est traitée de manière indépendante et le serveur ne conserve pas d’informations sur les requêtes précédentes ni sur l’état global de l’application pour traiter une nouvelle requête.

Architecture client-serveur

Le client et le serveur sont des entités distinctes qui communiquent via un protocole standardisé, généralement HTTP. Cette séparation permet une évolution indépendante des deux parties.

Mise en cache

Les réponses du serveur doivent indiquer si elles sont mises en cache ou non, pour améliorer les performances du réseau.

Système en couches

L’architecture peut comporter plusieurs couches entre le client et le serveur, comme des serveurs intermédiaires, des équilibreurs de charge ou des caches, qui sont invisibles pour le client.

Interface uniforme

REST utilise une interface standardisée pour la communication entre le client et le serveur. Cela inclut l’utilisation de méthodes HTTP standard (GET, POST, PUT, DELETE, etc.) et l’identification des ressources via des URLs.

Les API REST utilisent des endpoints, qui sont des adresses URL spécifiques où les ressources sont accessibles. Chaque endpoint correspond à une ressource unique, et la structure de ces URLs suit une logique hiérarchique.

Méthodes HTTP :

GET

Utilisé pour récupérer des données. Par exemple, une requête GET sur l’endpoint https://hostname/books récupère une liste de livres, tandis qu’une requête GET sur l’endpoint   récupère les détails du livre dont l’ID est 1.

POST

Utilisé pour créer de nouvelles ressources. Par exemple, une requête POST sur l’endpoint https://hostname/books avec les détails d’un nouveau livre dans le corps de la requête crée un nouveau livre.

PUT

Utilisé pour mettre à jour des ressources existantes. Par exemple, une requête PUT sur l’endpoint https://hostname/books/1 avec des données mises à jour dans le corps de la requête modifie les informations du livre dont l’ID est 1.

DELETE

Utilisé pour supprimer des ressources. Par exemple, une requête DELETE sur l’endpoint https://hostname/books/1  supprime le livre dont l’ID est 1.

 Ces méthodes HTTP permettent une interaction complète avec les ressources, chaque méthode étant dédiée à une opération spécifique, ce qui rend l’API intuitive et facile à utiliser.

Comprendre les API GraphQL

GraphQL est un langage de requête pour les API qui a été développé par Facebook en 2012 et publié en tant que projet open-source en 2015. Il a été créé à l’origine pour répondre aux limites et aux lacunes de REST. Il permet aux clients de définir la structure des données dont ils ont besoin, et aux serveurs de répondre avec exactement ces données, sans aucune donnée superflue ce qui est particulièrement utile dans les scénarios où le client a besoin d’un contrôle fin sur les données renvoyées.

Principes fondamentaux :

Schémas

Un schéma GraphQL définit les types de données et les relations entre eux, ainsi que les opérations possibles.

Types

Les types spécifient la forme des données (par exemple String, Int, Float, Boolean, etc.).

Requêtes

Les requêtes sont utilisées pour lire ou récupérer des valeurs. Elles permettent aux clients de spécifier exactement les champs de données dont ils ont besoin.

Mutations

Les mutations sont utilisées pour écrire ou modifier des valeurs, permettant la création, la mise à jour ou la suppression de données.

Résolveurs

Les résolveurs sont des fonctions qui mappent les requêtes et les mutations aux actions sur la base de données ou d’autres services.

Contrairement aux API REST, les API GraphQL utilisent un seul endpoint pour toutes les ressources où toutes les requêtes sont envoyées. Ce point d’accès unique reçoit toutes les requêtes GraphQL, ce qui simplifie la gestion et le routage des requêtes.

Les différences clés entre les API REST et GraphQL

Les principales différences entre ces deux technologies d’API sont les suivantes :

Endpoints

En REST, les endpoints sont fixes et chaque ressource est associée à un endpoint tandis qu’en GraphQL, il n’existe en général qu’un seul endpoint pour toutes les requêtes.

Flexibilité

L’une des limitations majeures de REST est que les réponses sont souvent fixes et peuvent contenir des données superflues (overfetching). De plus, il est souvent nécessaire de faire plusieurs requêtes avant d’obtenir certaines ressources (underfetching) ce qui peut entraîner une surcharge réseau. Il existe toutefois des alternatives comme les endpoints personnalisés, mais ce type d’endpoint n’est pas toujours simple à mettre en place et augmente la complexité du code. De plus, il est possible de remonter uniquement les données souhaitées en ajoutant des paramètres de requête spécifiques à l’URL pour filtrer les résultats selon certains critères ce qui est particulièrement utile dans certains cas.

GraphQL en revanche permet aux clients de demander uniquement les données dont ils ont besoin. Ce qui minimise la surcharge de données et permet de récupérer les informations souhaitées de façon plus efficace. De plus, une seule requête GraphQL permet d’accéder à plusieurs ressources liées contrairement à REST.

Versioning

Le versionnement, ou la gestion des versions, consiste à attribuer un identificateur unique à chaque version d’une API. Cela permet aux développeurs de différencier les différentes versions de l’API et de s’assurer qu’ils utilisent la version compatible avec leurs besoins.

En REST, le versionnement est indispensable lorsque l’API évolue pour maintenir la rétrocompatibilité et isoler les changements. En effet un changement au niveau de l’API sans versionnement peut casser les applications clientes qui dépendent de l’ancienne structure de l’API. Toutefois, cela peut vite devenir complexe à suivre et à gérer à mesure que l’API se développe.  Il est alors nécessaire de mettre en œuvre des bonnes pratiques permettant de limiter la coût de maintenance des anciennes versions d’API.

En GraphQL, le versionnement n’est pas nécessaire. Les évolutions de l’API se font en ajoutant de nouveaux champs ou types, tout en conservant les anciens pour maintenir la rétrocompatibilité. Cela simplifie grandement la gestion des modifications et permet une évolution continue de l’API sans rupture pour les clients.

Typage de données

Les types de données en REST sont souvent implicites et déduits de la structure JSON ou XML des réponses. De plus, la validation des types se fait généralement côté serveur et les développeurs doivent souvent se référer à la documentation de l’API pour comprendre les types de données attendus et retournés.

En GraphQL en revanche, il y a un système de typage fort. GraphQL utilise des schémas qui définissent formellement les types de données disponibles dans l’API. Tous les types sont explicitement déclarés pour chaque champ dans le schéma et cela peut être des types scalaires de base comme Int, Float, String, Boolean ou des types complexes personnalisés. De plus, GraphQL supporte les types non-nullables et les listes, ce qui permet une définition plus précise de la structure des données.

Caching

La mise en cache consiste à stocker les réponses des requêtes API fréquemment accédées dans un emplacement temporaire, tel que la mémoire vive ou le stockage local. Cela permet de réduire le temps de réponse et d’améliorer les performances des applications qui utilisent l’API.

La mise en cache est l’une des forces de REST. Cela est notamment dû à l’utilisation de mécanismes HTTP standard. Ce n’est pas le cas pour GraphQL, où la mise en cache est bien plus complexe en raison de la nature flexible des requêtes.

Maturité

En termes de maturité, REST est bien établi, largement adopté, et possède un écosystème mature et un support étendu à travers de nombreuses bibliothèques et frameworks. REST est la norme pour les API web depuis des années et est devenu le choix par défaut des développeurs qui cherchent stabilité et fiabilité.

GraphQL est une technologie relativement récente, mais connait toutefois une adoption  et croissante. L’écosystème GraphQL est dynamique, avec des outils et des bibliothèques en constante évolution, ce qui attire de plus en plus de développeurs.

Cas d’utilisation des deux types d’API

Il est recommandé d’utiliser les API REST dans les cas de figure suivants :

  • Les applications CRUD simples : les applications CRUD simples sont des applications logicielles qui se concentrent sur les opérations de base de gestion de données (Créer, Lire, Mettre à jour, Supprimer) pour un nombre limité d’entités ou de types de données. REST est souvent recommandé pour les applications CRUD simples pour son utilisation des méthodes HTTP standard (GET, POST, PUT, DELETE) qui correspondent naturellement aux opérations CRUD. Cela rend l’API intuitive et facile à comprendre pour les développeurs. REST offre un bon équilibre entre simplicité, standardisation et flexibilité, ce qui en fait un choix approprié pour ce type de projets ;
  • Les applications où la mise en cache est cruciale : comme on l’a vu précédemment, avec ses mécanismes de cache intégrés et sa flexibilité, REST est particulièrement bien adaptée aux applications où la mise en cache est un élément crucial pour les performances, l’efficacité et l’expérience utilisateur. De plus, les méthodes HTTP utilisées par REST, telles que GET, sont idempotentes, ce qui signifie que des requêtes identiques produiront des résultats identiques sans effets secondaires. Cela rend la mise en cache non seulement possible mais aussi efficace, car les clients peuvent être assurés que les données récupérées à partir du cache sont valides et à jour.

Quant aux API GraphQL, elles sont recommandées dans les cas suivants :

  • Les applications avec des exigences de données complexes : en effet, GraphQL permet aux développeurs de demander exactement les données dont ils ont besoin, dans la structure souhaitée. Cette flexibilité est cruciale pour les applications complexes où les besoins en données peuvent varier considérablement. De plus, contrairement aux API REST traditionnelles, GraphQL évite le problème de récupération excessive ou insuffisante de données. Cela optimise l’utilisation des ressources réseau et améliore les performances des applications ;
  • Les projets où la flexibilité est importante : dans des projets où les exigences peuvent évoluer rapidement, GraphQL permet d’ajouter de nouveaux champs et types au schéma sans rompre les requêtes existantes. Cela facilite l’évolution et la maintenance de l’API en permettant des modifications incrémentales et non disruptives, tout en assurant une compatibilité descendante.

Exemples d’entreprises utilisant REST ou GraphQL

Amazon

Amazon utilise largement les API REST pour ses différents services, en particulier pour Amazon Web Services (AWS). Voici quelques exemples :

  • Amazon S3 (Simple Storage Service) : l’API REST de S3 permet aux utilisateurs de gérer leurs objets stockés dans les buckets, y compris les opérations de création, lecture, mise à jour et suppression (CRUD). Par exemple, pour télécharger un fichier sur un bucket S3, on peut utiliser une requête PUT via l’API REST ;
  • Amazon EC2 (Elastic Compute Cloud) : l’API REST d’EC2 permet aux utilisateurs de lancer, arrêter et gérer leurs instances de serveurs virtuels. Les actions telles que la gestion des images machine (AMI), des clés SSH, et des configurations réseau peuvent toutes être réalisées via des appels REST ;
  • Amazon DynamoDB : DynamoDB expose une API RESTful pour interagir avec la base de données NoSQL, permettant des opérations de lecture et d’écriture sur des tables DynamoDB.

PayPal

PayPal a commencé à utiliser GraphQL en 2018 avec une seule application Checkout. Depuis lors, son utilisation s’est étendue à travers l’entreprise, devenant le modèle par défaut pour la construction de nouvelles applications UI.

PayPal a également fait face à des défis, notamment le manque de standardisation  dans GraphQL, ce qui a conduit à des efforts dupliqués entre les équipes et à des déviations par rapport aux méthodes standard de gestion de l’authentification.

L’adoption de GraphQL par PayPal a conduit à une amélioration significative de la productivité des développeurs, à des déploiements plus rapides et à une simplification de l’intégration pour leurs partenaires commerciaux.

Conclusion

En conclusion, le choix entre les API REST et GraphQL dépend largement des besoins spécifiques et des contraintes de chaque projet. REST, avec sa simplicité, sa standardisation et sa robustesse, reste une option solide pour les applications CRUD simples, les projets nécessitant une mise en cache efficace, et ceux où les endpoints et opérations sont bien définis. Son écosystème mature et largement adopté en fait un choix par défaut pour de nombreux développeurs.

D’un autre côté, GraphQL se démarque par sa flexibilité et sa capacité à répondre aux besoins de données complexes et changeantes. En permettant aux clients de demander exactement les données dont ils ont besoin, GraphQL évite le surchargement et le sous-chargement de données, optimisant ainsi l’utilisation des ressources réseau. Sa structure unique avec un seul endpoint et son schéma fortement typé simplifient la gestion des évolutions de l’API sans nécessiter de versionnement, ce qui en fait un choix idéal pour les projets nécessitant une grande agilité.

Les exemples d’Amazon et PayPal illustrent bien cette dualité : Amazon privilégie REST pour la robustesse et la simplicité de gestion de ses nombreux services, tandis que PayPal a adopté GraphQL pour améliorer la productivité des développeurs et simplifier les intégrations complexes. Ainsi, la décision de choisir entre REST et GraphQL doit être prise en fonction des cas d’utilisation spécifiques, des exigences en matière de performance et de flexibilité, et de la vision à long terme de l’évolution de l’API. Toutefois, il est important de garder à l’esprit qu’il est possible, et parfois même souhaitable, de ne pas se cantonner à l’utilisation d’une seule technologie pour bénéficier de la complémentarité des avantages.

 

Sources

Article précédent Radar des startups Smart Building - Smart Office
Article suivant L’avenir des frameworks d’agilité à l’échelle

Sur le même thème

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *