Qu'est-ce qu'une API REST ?
Le style d'architecture REST ou API RESTful (Representational State Transfer) est conçu pour tirer parti des protocoles existants. Même si REST est utilisable sur presque tous les protocoles, il exploite généralement le protocole HTTP pour les APIs Web. Ainsi, les développeurs n'ont pas besoin d'installer de bibliothèques ou de logiciels supplémentaires pour profiter du style d'architecture API REST. Le style d'architecture API REST a été défini en 2000 par le Dr. Roy Fielding dans sa thèse de doctorat. Ce style d'architecture d'API se distingue par son incroyable niveau de flexibilité. Comme les données ne sont pas liées aux méthodes et aux ressources, REST peut traiter plusieurs types d'appels, renvoyer différents formats de données et même changer de structure avec la mise en œuvre correcte de l'hypermédia.
Cette liberté et cette flexibilité inhérentes au style d'architecture API REST vous permettent de créer une API qui répond à vos besoins, ainsi qu'à ceux de clients très divers. Contrairement à SOAP, REST n'est pas limité à XML, mais peut renvoyer XML, JSON, YAML ou tout autre format en fonction de la demande du client. Et à l'inverse du protocole RPC, les utilisateurs n'ont pas besoin de connaître les noms de procédures ou les paramètres spécifiques dans un ordre précis.
Toutefois, le style d'architecture API REST présente également des inconvénients. Vous pouvez notamment perdre votre capacité à maintenir l'état dans REST, comme dans les sessions. Les nouveaux développeurs peuvent en outre rencontrer des difficultés lors de son utilisation. Avant de concevoir votre API, il est également important de comprendre ce qui constitue une API REST RESTful et pourquoi ces contraintes existent. Après tout, si vous ne comprenez pas pourquoi une chose est conçue d'une certaine manière, vous risquez d'entraver vos efforts sans même vous en rendre compte.
Comprendre le style d'architecture API REST
Si la plupart des APIs sont considérées comme RESTful, elles ne répondent pourtant pas aux exigences et contraintes énoncées par le Dr Roy Fielding. Le style d'architecture REST API présente six contraintes clés à prendre en compte lorsque vous décidez du bon type d'API pour votre projet.
1. Architecture Client-serveur
La contrainte client-serveur repose sur le concept selon lequel le client et le serveur doivent être séparés l'un de l'autre et autorisés à évoluer individuellement et indépendamment. En d'autres termes, je dois pouvoir apporter des modifications à mon application mobile sans affecter la structure des données ou la conception de la base de données sur le serveur. Parallèlement, je dois pouvoir modifier la base de données ou apporter des changements à mon application serveur sans que cette opération affecte le client mobile. Ainsi, les problèmes sont dissociés. Chaque application peut croître et évoluer indépendamment de l'autre, et votre entreprise peut se développer rapidement et efficacement.
2. Sans état
Les APIs REST sont sans état, ce qui signifie que les appels peuvent être réalisés indépendamment les uns des autres et que chaque appel contient toutes les données nécessaires pour être mené à bien. Une API REST ne doit pas dépendre des données stockées sur le serveur ou des sessions pour déterminer ce qu'il convient de faire avec un appel, mais uniquement des données fournies dans cet appel. Les informations d'identification ne sont pas stockées sur le serveur lorsque des appels sont réalisés. À la place, chaque appel dispose des données nécessaires, telles que la clé API, le jeton d'accès, l'ID de l'utilisateur, etc. Cela permet également d'accroître la fiabilité de l'API en disposant de toutes les données nécessaires à la réalisation de l'appel, plutôt que de s'appuyer sur une série d'appels avec l'état du serveur pour créer un objet, au risque d'entraîner des échecs partiels. À la place, afin de réduire les besoins en mémoire et de maintenir l'évolutivité de votre application, une API RESTful exige que tout état soit stocké sur le client, et non sur le serveur.
3. La gestion du cache avec l’API REST
Étant donné qu'une API sans état peut augmenter la surcharge des requêtes en traitant de grandes quantités d'appels entrants et sortants, une API REST doit être conçue de manière à encourager le stockage de données pouvant être mises en cache. Ainsi, lorsque les données peuvent être mises en cache, la réponse doit indiquer que les données peuvent être stockées jusqu'à un certain moment (expires-at). Lorsque les données doivent être en temps réel, la réponse ne doit pas être mise en cache par le client. Cette contrainte importante vous permettra non seulement de réduire considérablement le nombre d'interactions avec votre API, ce qui diminuera l'utilisation du serveur interne, mais également d'offrir à vos utilisateurs d'API les outils nécessaires pour fournir les applications les plus rapides et les plus efficaces possible. N'oubliez pas que la mise en cache s'effectue du côté du client. Même si vous pouvez mettre en cache certaines données au sein de votre architecture afin d'améliorer les performances globales, l'objectif est d'indiquer au client comment il doit procéder et s'il peut ou non stocker temporairement les données.
4. API REST : une interface uniforme
La clé du découplage entre le client et le serveur réside dans une interface uniforme qui permet une évolution indépendante de l'application sans que les services, les modèles ou les actions de l'application soient étroitement liés à la couche d'API. L'interface uniforme permet au client de communiquer avec le serveur dans un seul langage, indépendamment du back-end architectural de l'un ou de l'autre. Cette interface REST doit fournir un moyen de communication constant et standardisé entre le client et le serveur, par exemple en utilisant le protocole HTTP avec des ressources URI, CRUD (Create, Read, Update, Delete) et JSON.
5. Le système multicouche de l’API REST
Comme son nom l'indique, un système multicouche est un système composé de plusieurs couches. Chaque couche possède une fonctionnalité et une responsabilité spécifiques. Prenons l'exemple d'un cadre Modèle-vue-contrôleur : chaque couche possède ses propres responsabilités. Les modèles contiennent la manière dont les données doivent être formées, le contrôleur se concentre sur les actions entrantes et la vue sur les actions sortantes. Chaque couche est dissociée, mais interagit avec les autres. Dans le style d'architecture API REST, le même principe s'applique. Les différentes couches de l'architecture travaillent ensemble pour construire une hiérarchie qui favorise la création d'une application plus évolutive et modulaire.
Un système multicouche vous permet également d'encapsuler les systèmes legacy et de déplacer les fonctionnalités les moins couramment utilisées vers un intermédiaire partagé, tout en protégeant les composants plus modernes et couramment utilisés. De plus, le système multicouche vous permet de déplacer librement des systèmes à l'intérieur et à l'extérieur de votre architecture REST à mesure que les technologies et les services évoluent, augmentant ainsi la flexibilité et la longévité, à condition que les différents modules restent associés de la manière la plus souple possible. Le système multicouche présente des avantages considérables en matière de sécurité . Il vous permet de parer les attaques au niveau de la couche du proxy ou d'autres couches, empêchant les attaques d'atteindre l'architecture réelle de votre serveur. L'utilisation d'un système multicouche avec un proxy ou la création d'un point d'accès unique vous permet de garder les éléments critiques et les plus vulnérables de votre architecture REST derrière un pare-feu, empêchant ainsi toute interaction directe entre eux et le client. Souvenez-vous que la sécurité ne repose pas sur une solution unique qui « pare toutes les attaques », mais sur l'existence de plusieurs couches. De plus, certains contrôles de sécurité peuvent échouer ou être contournés. Ainsi, plus vous mettez en place des mesures de sécurité dans votre système, plus vous avez de chances de prévenir les attaques préjudiciables.
6. Code à la demande avec l’API REST
Sans doute la moins connue des six contraintes (et la seule facultative), le code à la demande permet de transmettre du code ou des applets via l'API pour les utiliser dans l'application. En somme, il crée une application intelligente qui ne dépend plus uniquement de sa propre structure de code. Cependant, sûrement parce qu'il est en avance sur son temps, le code à la demande a eu du mal à être adopté, les APIs Web étant utilisées par plusieurs langages et la transmission du code soulevant des questions et des problèmes de sécurité. (Par exemple, le répertoire doit être accessible en écriture et le pare-feu doit laisser passer le contenu normalement restreint.)
Ensemble, ces contraintes définissent l'architecture REST, ou Representational State Transfer. En les parcourant, vous pourrez comprendre comment chaque contrainte successive s'ajoute à la précédente, pour finalement créer une API relativement complexe, mais également puissante et flexible. Mais plus important encore, ces contraintes constituent un style d'architecture qui fonctionne de manière similaire à la façon dont nous accédons aux pages dans nos navigateurs sur le Web. Il crée une API dictée par les représentations qu'elle renvoie, et non par son architecture, ainsi qu'une API qui, bien qu'architecturalement sans état, s'appuie sur la représentation pour dicter l'état de l'application.