Consommer des API REST et GraphQL
Plusieurs types d’API (REST et GraphQL)
1. Définition et historique
Une API (Application Programming Interface) est une interface de programmation d’application. API est un terme générique qui concerne aussi bien les interfaces permettant à plusieurs composants d’application de communiquer entre eux (nous l’avons vu avec quelques API natives du navigateur, par exemple l’API DOM, LocalStorage, etc.) que les interfaces permettant la communication entre plusieurs applications.
Aujourd’hui, avec l’avènement des architectures SOA (Services Oriented Architecture) ou microservices dans les entreprises (services métiers côté backend déclinés en web services), nous utilisons également des API web pour faire communiquer des Web Services entre eux via Internet ou le réseau interne des entreprises, avec le protocole de transport HTTP principalement.
Aujourd’hui, sur Internet, on utilise couramment le terme API pour désigner des interfaces d’applications web qui permettent à des applications côté client (frontend) de dialoguer avec des applications côté serveur (backend).
Par le passé, on a d’abord utilisé des API SOAP (Simple Object Access Protocol). C’est un protocole qui était utilisé pour échanger des objets du langage Java ou C#, par exemple, avec le navigateur ou entre serveurs via des messages au format XML.
Mais ce protocole d’échange avait deux inconvénients majeurs :
-
Le format XML est beaucoup plus descriptif que le format JSON, les messages pouvaient donc être très volumineux.
-
SOAP décrit via l’intermédiaire du XML comment les applications doivent communiquer entre elles, ce qui implique un couplage fort entre l’application côté client et l’application côté serveur. Une modification de l’API côté serveur nécessite donc nécessairement une modification côté client.
2. API REST
a. Définition
Un autre type d’API Web qui ne possède pas ces défauts est maintenant couramment utilisé, les API REST (Representational State Transfer).
L’idée de ce style d’architecture est de pouvoir accéder de manière normalisée...
Sécurité et modes d’authentification
1. Principes à adopter
Utiliser le protocole HTTPS
S signifie Secure. Ce protocole est le même que le protocole HTTP, à ceci près qu’il ajoute une couche de sécurité supplémentaire TLS (Transport Layer Security) qui fonctionne de la manière suivante :
-
Le client contacte un serveur et lui demande une connexion sécurisée en proposant une liste de méthodes de chiffrement de la connexion.
-
Le serveur choisit une méthode qu’il peut utiliser et renvoie au client un certificat (suite chiffrée) qui contient une clé publique. Ce certificat est délivré par une autorité de certification (l’équivalent d’un notaire), et prouve que le serveur a une identité vérifiée et sûre. Cela permet de se prémunir des attaquants qui "sniffent" la connexion via un serveur pirate positionné entre le client et le serveur. Le client peut alors, avec cette clé publique, crypter les données qu’il envoie. Le serveur peut ensuite décrypter le message à l’aide la clé privée fournie avec le certificat par l’autorité de certification.
Il est fortement recommandé d’utiliser ce protocole pour communiquer avec l’API backend de votre application.
Ne pas utiliser de paramètres dans l’URL pour des données sensibles
Lorsqu’on utilise une API REST, on utilise les méthodes HTTP POST, PUT, PATCH et DELETE. GET et DELETE n’utilisent pas de corps de requête (Body). Si vous envoyez des paramètres, ils seront donc placés dans l’URL.
Si vous envoyez des identifiant et mot de passe via une requête GET, ils seront alors conservés dans l’historique du navigateur. Une personne ayant accès à votre ordinateur pourra donc les récupérer pour les réutiliser.
De même, sans faire attention, un utilisateur non averti pourrait poster cette URL sur un forum, réseau social ou dans un mail sans se douter qu’il partage du même coup ces identifiant et mot de passe.
Une URL est limitée à 2 000 caractères, alors que le corps d’une requête peut contenir plusieurs mégaoctets, dans...
Créer une API rapidement avec Strapi
1. Créer le backend de votre API
a. Présentation
Nous allons maintenant rentrer dans le vif du sujet et voir comment consommer une API REST et une API GraphQL. Pour cela, nous allons au préalable utiliser Strapi pour créer rapidement une API : https://strapi.io/. Strapi est une solution pour créer rapidement une API REST et GraphQL. Il a été développé par une jeune start-up française fondée en 2018. Strapi peut également servir en tant que CMS Headless.
Il permet de créer le code backend d’une API en quelques lignes de commande et une interface graphique front-office permet aux utilisateurs d’ajouter du contenu. Strapi peut utiliser plusieurs bases de données comme SQLite, MySQL, PostgreSQL, MariaDB et MongoDB. L’API peut ensuite être déployée sur un serveur Node.js ou un hébergeur PaaS comme Netlify ou Heroku.
Pour une API REST, Strapi permet d’utiliser des paramètres de tri, filtres, et de pagination dans vos URI.
Il est également possible d’utiliser plusieurs plugins pour ajouter des fonctionnalités supplémentaires.
Liste des plugins officiels maintenus par la core team de Strapi :
-
Documentation API : pour générer automatiquement une documentation en ligne de votre API avec l’interface graphique Swagger.
-
Email : pour l’envoi d’e-mails, également de manière planifiée. Il est aussi possible d’utiliser un service tiers d’envoi d’e-mails pour des campagnes d’e-mailing, comme SendGrid ou MailChimp.
-
GraphQL : par défaut, Strapi crée une API REST. Ce plugin permet, en plus, de générer une API GraphQL. Il met également à disposition un client graphique GraphQL avec une fonctionnalité d’autocomplétion par rapport au schéma GraphQL généré, pour interroger l’API et tester vos requêtes.
-
Upload : pour télécharger des fichiers sur le serveur backend ou sur un service comme Amazon S3.
-
Roles et permissions : pour gérer l’authentification de vos utilisateurs en utilisant la méthode Bearer + JWT et gérer les différentes permissions des utilisateurs. Si vous souhaitez...
Fetch et Axios pour consommer des API REST
1. Fetch
a. Définition et usage
Fetch est une API native, disponible dans tous les navigateurs modernes, pour envoyer des requêtes HTTP asynchrones. Cette API remplace désormais l’ancienne méthode utilisée pour faire des requêtes AJAX (Asynchronous JavaScript And XML) via l’objet XMLHttpRequest. Elle est plus flexible et propose de puissantes fonctionnalités :
-
Elle utilise les objets natifs Request et Response ; elle est donc particulièrement adaptée pour être utilisée via des ServiceWorkers ou pour alimenter l’API Cache du navigateur.
-
Elle utilise les concepts CORS et permet de définir les en-têtes des requêtes.
La méthode fetch() prend en premier paramètre l’URI du point de terminaison d’une API et, optionnellement, en second paramètre un objet d’options.
let promesse = fetch("URI", {/* options */});
Lorsque fetch() reçoit la réponse du serveur, elle renvoie une promesse tenue, peu importe le statut HTTP (200+, 300+, 400+ ou 500) avec en valeur de résolution un objet Response.
On appelle ensuite la fonction .json() de l’objet Response, qui renvoie une promesse résolue avec, en valeur de résolution, les données du corps de la réponse au format JSON.
let promesse = fetch("URI", {/* options */});
promesse.then(reponse => {
console.log(reponse.json());
));
b. Les objets Request et Response
Plutôt que de passer l’URI en premier paramètre, vous pouvez également fournir à la place un objet Request. Le constructeur de l’objet Request prend exactement les mêmes paramètres que fetch() :
const request = new Request("monURI", {/* options */ });
let promesse = fetch(request));
Comme les options de l’objet Request sont les mêmes que les options de fetch(), nous passerons directement les options à fetch() par la suite.
Les propriétés de l’objet Request :
Propriété |
Description |
method |
La méthode HTTP employée : "GET", "POST", "PUT", "DELETE", "PATCH", "OPTIONS". |
mode |
Le mode CORS de la requête, qui prend... |
Apollo pour consommer des API GraphQL
1. Installation
a. Installation avec Vue CLI
Apollo est un ensemble d’outils permettant de créer une API GraphQL côté serveur et de consommer n’importe quelle API GraphQL côté client.
Pour en savoir plus : https://www.apollographql.com/
La communauté Vue.js a développé le plugin Vue Apollo pour pouvoir intégrer le client Apollo facilement dans un projet Vue.js. La documentation officielle est disponible à l’adresse suivante : https://vue-apollo.netlify.app/
Il existe différents types d’installation. Le plus simple est d’utiliser Vue CLI lorsque vous utilisez une API GraphQL créée avec Apollo (ce n’est pas notre cas avec Strapi).
Vous pouvez ainsi :
-
Installer un projet backend utilisant le serveur Apollo pour votre API.
-
Installer le moteur qui permet d’utiliser un schéma GraphQL créé sur le site Apollo.
-
Installer et configurer le client GraphQL.
-
Générer des exemples de code dans votre projet frontend pour consommer votre API backend Apollo.
Si vous utilisez Vue CLI, le plugin peut s’installer très facilement sans aucune configuration avec la commande suivante :
vue add apollo
Il est également possible de l’installer via l’interface graphique :
vue ui
b. Installation manuelle pour consommer une API Strapi
Nous utilisons l’API GraphQL de Strapi. Nous allons donc installer uniquement les éléments nécessaires suivants pour la consommer :
-
vue-apollo : pour l’intégration avec Vue.js.
-
graphql : pour utiliser la syntaxe de requête GraphQL.
-
apollo-client : pour consommer une API GraphQL.
-
apollo-link : permet l’utilisation d’interfaces pour l’envoi et la réception de réponse GraphQL avec le client Apollo.
-
apollo-link-http : permet d’utiliser l’interface http avec apollo-link.
-
apollo-cache-inmemory : permet de conserver la réponse de vos requêtes GraphQL en cache pour ne pas les réexécuter plusieurs fois si vous utilisez les mêmes données.
-
graphql-tag : permet de parser les requêtes GraphQL définies en chaîne de caractères dans le code et de les convertir au format AST (Abstract Syntax Tree) pour être utilisées...