Pour construire une API, vous avez le choix entre SOAP, gRPC, REST, GraphQL… mais comment choisir ?
SOAP, protocole avec des exigences spécifiques, est aujourd’hui totalement déprécié et utilisé uniquement dans de très grosses sociétés qui ont plus de difficultés à opérer un virage dans leur stack technologique.
gRPC, peu adapté à l’usage web c’est un service dont l’usage se tourne plutôt vers la technique pour faire communiquer des applications utilisant des langages différents entre elles.
Concentrons-nous aujourd’hui sur le choix entre REST et GraphQL.
Souvent étiqueté comme un meilleur REST, GraphQL aide en effet à résoudre certaines problématiques auxquelles les développeurs sont confrontés lors de la création d’API REST.
Alors est-ce vrai ? Dans les faits REST et GraphQL sont deux méthodes bien différentes qui ont chacune des avantages et des inconvénients.
Explorons alors la différence qui existe entre ces deux technologies.
1. Qu’est-ce qu’une API RESTful ?
REST ou (Representational State Transfer) est un ensemble de normes et de principes architecturaux qui structurent la façon dont vos données doivent transiter au sein de votre application ou avec les services externes.
Les API RESTful se basent sur le protocole HTTP pour transférer de la donnée.
NB : Le terme RESTful est utilisé pour parler des API REST, néanmoins toutes les API REST sont des API mais toutes les API ne sont pas RESTful.
REST est généralement préférée à d'autres technologies similaires car REST utilise moins de bande passante.
a. Comment fonctionne une API RESTful ?
Comme nous l’avons déjà évoqué, les API REST se basent sur le protocole HTTP.
Les méthodes les plus courantes sont les suivantes :
L’utilisation de GET par le client, lui permet d'accéder aux ressources se trouvant à l’URL spécifié sur le serveur.
Si vous souhaitez obtenir la liste de vos utilisateurs vous utiliserez donc la requête suivante :
GET /users
De la même manière si vous souhaitez obtenir les détails sur un utilisateur en particulier alors vous utiliserez :
GET /users/1
L’utilisation de POST par le client, lui permet d’envoyer des données au serveur.
Si vous souhaitez créer un nouvel utilisateur vous utiliserez donc la requête suivante :
POST /users
L'utilisation de PUT par le client, lui permet de mettre à jour des ressources existantes sur le serveur.
Pour mettre à jour un utilisateur existant vous utiliserez donc :
PUT /users/1
L’utilisation de DELETE par le client, lui permet de supprimer des ressources existantes sur le serveur.
Pour supprimer un utilisateur vous devrez donc utiliser :
DELETE /users/1
NB : Si l’utilisateur ne possède pas les droits appropriés alors la requête échouera.
2. Les avantages de REST
a. Courbe d’apprentissage
Par rapport aux autres types d’API, les API RESTful ont l’avantage d'être plus facile à apprendre.
b. Meilleurs temps de chargement
La mise en cache et le stockage des données permettent de réduire le nombre d'interactions entre le client et le serveur. Ainsi le temps de chargement s’en trouve amélioré.
NB : L’utilisation du “caching” n’est pas conseillée. En effet, le risque est que vous fassiez un appel API vous retournant des données périmées s’il n’y a pas eu de refresh du cache.
De plus avec les technologies actuelles telles que le Serverless il est facile d’obtenir des temps de chargement aussi rapide voir meilleurs sans utilisation de cette méthode.
c. Maintenabilité
La structuration des requêtes imposée par le fait que les API RESTful soient stateless vous permet en tant que développeur de comprendre facilement une ancienne requête API déjà existante le code.
d. Indépendance
Les API REST sont décorrélées de la technologie utilisée. Vous pouvez donc écrire vos applications client-serveur dans le langage de votre choix sans affecter votre API. De la même manière, si vous changez la technologie sous-jacente d’un côté ou de l’autre cela n’aura pas d’impact.
3. Les inconvénients de REST
a. Allers-retours multiples
Les API REST sont constitués de points de terminaison nombreux. Vous devrez donc augmenter le nombre de requêtes pour obtenir l’ensemble des ressources dont vous avez besoin.
b. Over-fetching et Under fetching
En plus de devoir faire plusieurs requêtes pour obtenir les ressources dont vous avez besoin, vous serez aussi confronté à l’une des plus grosses limitations de REST. De par sa conception, REST permet l’accès aux données uniquement via des points de terminaisons qui renvoient des ensembles de données fixes.
Cela se traduit donc par l’obtention d’un surplus d’informations dans certains cas ou à l’inverse un manque d’informations.
c. Hiérarchie
Les API REST fonctionnent avec des identifiants de ressource uniforme (URI) ce qui les rends moins adaptées pour fonctionner avec des ressources organisées de manières différentes.
d. Stateless
Par sa condition stateless, le serveur ne stocke pas les requêtes ou réponses précédentes. Cela implique qu’il ne sait pas si une requête est faite pour la première fois ou non. Elle doit donc être traitée à partir de zéro à chaque fois.
4. Qu’est-ce qu’une API GraphQL ?
GraphQL est un langage de requête et de manipulation de données open source pour les API, ainsi qu'un moteur d'exécution permettant d'effectuer des requêtes avec des données existantes.
GraphQL a été créé par Facebook, et rendu public en 2015, dans le but d’améliorer l’expérience des développeurs d’applications mobiles travaillant avec des API REST.
Les API GraphQL se basent également sur le protocole HTTP pour transférer de la donnée. La différence notable avec REST est que GraphQL permet de faire du temps réel.
Ce qui fait le succès de GraphQL est la possibilité de demander et recevoir uniquement les données dont vous avez besoin et rien d’autre. Cela facilite l’évolution de vos API au cours du temps.
5. Les avantages de GraphQL
a. Le data Fetching
Contrairement à REST, avec GraphQL vous pouvez requêter uniquement les ressources dont vous avez besoin. Cela vous offre un gain en terme de nombres de requêtes à effectuer pour récupérer l’ensemble des données recherchées.
Prenons un exemple dans lequel vous souhaitez afficher les détails d’un produit :
query webProductQuery {
product(id: 1) {
namecolorsize
category
price
imageURL
}
}
Cette requête peut aussi être simplifié si le viewport est plus petit (mobile) :
query mobileProductQuery {
product(id: 1) {
name
price
imageURL
}
}
Vous pouvez mieux comprendre la différence de récupération des ressources avec une API REST vs GraphQL avec l’illustration suivante.
b. Pas d’over-fetching ou under-fetching
Conséquence directe du Data fetching, avec GraphQL, fini l’over et l’under fetching puisque vous pouvez demander les ressources exactes dont vous avez besoin dans vos requêtes.
c. Maintenabilité accrue
GraphQL offre une maintenabilité accrue grâce à un ensemble d’outils intégrés :
Vous pouvez tester l’outil en cliquant ici.
d. Le temps réel
GraphQL offre la possibilité d’obtenir des mises à jour en temps réel du serveur avec les subscriptions.
A l’aide d’une fonction comme celle-ci dessous :
subscription {
online_users {
id
last_seen
user {
name
}
}
}
Vous pourrez visualiser l’ensemble des utilisateurs en ligne à chaque fois que celui-ci changera.
Cela s’avère particulièrement utile lorsque vous travaillez à plusieurs pour éviter les conflits de version.
e. Batching
Avec GraphQL vous pouvez encapsuler plusieurs requêtes en une.
Prenons un exemple dans lequel vous souhaitez afficher le nom et prénom d’un utilisateur et le prénom d’un second.
Avec REST vous devrez effectuer deux requêtes comme suit :
query {
user (id:1) {
id
firstName
lastName
}
}
Puis une seconde pour le second utilisateur
query {
user (id:2) {
id
firstName
}
}
Tandis qu’avec GraphQL vous pourrez les encapsuler comme ceci :
query {
user (id:1) {
id
firstName
lastName
}
}
user (id:2) {
firstName
}
f. Flexibilité
GraphQL étant flexible par nature grâce au schéma, vous pouvez apportez des modifications côté client sans besoin d’effectuer des actions côté serveur.
Ceci est une conséquence directe du data fetching. En effet, la possibilité de spécifier les données dont vous avez besoin, permet de moins avoir à modifier votre back-end si le besoin de données de votre front-end évolue.
6. Les inconvénients de GraphQL
a. Courbe d’apprentissage
GraphQL nécessite des connaissances de base, surtout concernant la conception du schéma. Néanmoins les gains en performance et la complexité des API que vous pouvez construire valent l’investissement.
b. Mise en cache web
GraphQL ne s'appuie pas sur les méthodes de mise en cache HTTP. Il reste néanmoins possible et simple de mettre en place un système de cache via la mise en place d’un “unique identifier" par exemple.
7. Pourquoi avons-nous choisi GraphQL chez Nuage ?
a. Performances
Il ne fait aucun doute que GraphQL est plus performant que les API RESTful en raison de sa capacité à ne requêter que les données effectivement souhaitées par le client : les appels aux bases de données ou APIs sous-jacentes ainsi évitées génèrent un gain substantiel à l’échelle.
b. Complexité des requêtes
Avec GraphQL, les requêtes étant réunies en un seul point de terminaison, ces requêtes peuvent devenir plus complexes au fil du temps.
Pour REST, les points de terminaisons étant multiples, les requêtes doivent rester simples et il va falloir les multiplier pour récupérer les données que vous souhaitez.
Il n’est d’ailleurs pas rare de constater dans les entreprises utilisant les API RESTful, un cumul de centaines d’API dont on ne sait plus bien à quoi elles servent.
c. Popularité et support de la communauté
Avec un taux d’adoption grandissant, GraphQL est en pleine expansion et devrait continuer son ascension dans les années à venir.
REST, implanté depuis plus longtemps possède une communauté bien implantée et il est par conséquent plus facile de trouver des développeurs maîtrisant la technologie des API REST.
d. Courbe d’apprentissage
En ce qui concerne la courbe d’apprentissage, REST étant intégré dans la plupart des principaux langages de programmation et des frameworks populaires, il est assez simple à prendre en main et nécessite moins de connaissances au départ.
En toute logique GraphQL exige de meilleures connaissances pour se lancer. Néanmoins les gains en performance et la complexité des API que vous pouvez construire valent l’investissement.
e. Schéma typé
Avec GraphQL, les API exposées au client sont écrites en SDL. Ces schema définissent les règles d’accès au serveur par le client. Ce mode de fonctionnement permet d’éviter les incohérences de données qui peuvent parfois survenir avec les API RESTful.
f. L’over fetching ou l’under fetching
Comme nous l’avons exposé précédemment, la construction des API RESTful en plusieurs points de terminaisons et la multiplicité des requêtes entraîne parfois une remontée de données excessive ou insuffisante.
GraphQL résout ce problème avec le Data Fetching et le point de terminaison unique. Vous obtenez les données dont vous avez besoin, rien de plus, rien de moins.
g. Les points de terminaison
Comme nous l’avons évoqué plusieurs fois, GraphQL réunit les informations en un seul point de terminaison. Ce qui est un très gros avantage sur les API REST.
Prenons un exemple dans lequel vous souhaitez afficher les détails d’un produit avec son numéro d’identifiant.
Avec REST vous devrez utiliser un point de terminaison comme suit :
/users/1/
Maintenant pour afficher les avis concernant ce produit, vous devrez envoyer votre requête à un autre point de terminaison comme suit :
/users/1/reviews
Supposons que vous souhaitiez maintenant afficher les photos du produit :
/users/1/photos
Pour réunir ces informations en un seul point de terminaison il vous faudrait donc développer :
/users/1/photos_and_reviews
Et soyons honnête cela serait du bricolage.
Avec GraphQL et le Data Fetching, vous pourrez récupérer ces informations sans aucun soucis en seul point de terminaison :
query webProductQuery {
product(id: 1) {
namesize
category
photos {
url
}
reviews {
date
body
}
}
}
h. Rapidité de développement
Avec une API REST vous devez construire vos points de terminaison en fonction des vues de votre application.
Le problème avec cette approche est que dès que vous souhaitez apporter une modification à votre Front-end vous risquez de récupérer plus de données ou moins de données qu’avec votre requête antérieure. Vous devrez donc également modifier votre Back-end pour que les modifications apportées au Front soient prises en compte.
Grâce au Data Fetching, GraphQL est plus flexible ce qui vous permet d’apporter des modifications à votre Front sans vous préoccuper de votre Back.
8. Résumé
Alors GraphQL ou REST ?
Vous l’aurez bien compris, donner une réponse ferme et définitive n’est pas chose aisée puisque les deux technologies offrent leur lot d’avantages et d’inconvénients.
Néanmoins chez Nuage, nous avons fait notre choix, et c’est GraphQL.
Même s’il est plus récent et possède par conséquent une communautée moins grande, GraphQL représente un choix judicieux car il permet notamment de résoudre les problèmes rencontrés lors de la construction d’API RESTful tout comme le fut REST en son temps face à SOAP.
GraphQL est aujourd’hui une option de choix pour construire des API complexes, rapides avec un schéma strict permettant un accès cohérent à vos données, le tout réuni en un seul point de terminaison.
