Qu’est-ce qu’une API REST ?

Une API REST est un type d’interface de programmation d’application (API) conforme au modèle de transfert d’état représentationnel (REST), qui définit la représentation des données et la communication entre deux systèmes (un client et un serveur) sur un réseau tel qu’Internet. Les API REST permettent l’échange d’informations entre des applications internes et tierces, et permettent aux entreprises d’intégrer plusieurs points de terminaison à leur écosystème applicatif.

Remarque : à proprement parler, REST désigne le modèle et n’est pas un adjectif qualifiant une API qui s’y conforme, pour laquelle le terme approprié est API RESTful. Cependant, API REST est l’expression la plus couramment employée et c’est donc celle qui est utilisée dans cet article.

Qu’est-ce que REST ?

REST, qui, comme indiqué précédemment, signifie « transfert d’état représentationnel », est un style d’architecture créé par l’informaticien Roy Fielding en 2000. REST offre une grande flexibilité aux développeurs, ce qui le rend idéal pour connecter des applications dans des architectures de microservices.

REST définit six contraintes que les applications et les API doivent respecter pour être considérées comme RESTful :

Interface uniforme
Architecture client-serveur
Absence d’état
Système en couches
Mise en cache
Code à la demande

Vous pouvez en savoir plus sur ces contraintes sur Wikipédia.

Interface uniforme

Une interface uniforme simplifie l’architecture globale du système et améliore la visibilité des interactions. Elle impose également des exigences spécifiques afin de garantir que les informations sont transférées dans un format standard.

Quatre contraintes permettent d’uniformiser une interface REST :

Chaque ressource possède un identifiant unique, tel qu’un URI, et sa représentation dans un message est distincte de sa représentation interne sur le serveur.
La représentation de la ressource contient suffisamment d’informations pour permettre au client de modifier ou de supprimer l’état d’une ressource
Chaque message contient suffisamment d’informations pour indiquer comment le traiter
Le serveur utilise des hyperliens pour informer les clients des ressources disponibles, leur évitant ainsi d’avoir à connaître le fonctionnement interne du serveur

Client-serveur

Une architecture client-serveur se compose de clients, de serveurs et de ressources. La séparation de l’interface utilisateur (contrôlée par le client) et du stockage des données (contrôlé par le serveur) permet aux composants client et serveur d’évoluer de manière autonome. Elle facilite également la portabilité de l’interface utilisateur du client sur plusieurs plateformes, ainsi que la mise à l’échelle du serveur.

Sur Internet, l’interaction client-serveur s’effectue via HTTP.

Absence d’état

Dans les communications client-serveur, l’absence d’état signifie que le serveur ne conserve aucune information sur le client ni sur la session établie avec celui-ci. Les informations relatives à la session transmises par le client dans chaque message doivent permettre au serveur de comprendre ce dernier de manière autonome, sans avoir besoin du contexte des messages précédents. Cela réduit la charge du serveur et améliore les performances des applications traitant de gros volumes de données.

Système en couches

Les clients n’ont pas besoin de savoir s’ils sont connectés directement au serveur ou à un intermédiaire tel qu’un proxy inverse ou un répartiteur de charge (et ils ne peuvent généralement pas faire la différence). Les serveurs intermédiaires contribuent à améliorer l’évolutivité et peuvent prendre en charge la sécurité, afin que les serveurs n’aient à gérer que la logique métier.

Mise en cache

Les clients HTTP et les intermédiaires peuvent mettre en cache les réponses du serveur afin de réduire la charge de ce dernier et d’accélérer la transmission des données aux utilisateurs finaux. Le serveur doit indiquer si une réponse peut ou non être mise en cache. Dans ce dernier cas, cela garantit que les réponses aux requêtes ultérieures des utilisateurs finaux sont correctes et à jour (et non potentiellement « obsolètes »). Comme les clients accèdent à une ressource par son URL, qui constitue un identifiant unique, ils peuvent déterminer les éléments à mettre en cache au niveau de la ressource.

Code à la demande

Le code à la demande signifie que le serveur peut envoyer du code exécutable afin d’étendre ou de personnaliser temporairement les fonctionnalités du client, sans que celui-ci ait à les implémenter lui-même. La contrainte de code à la demande est facultative.

Qu’est-ce qu’une ressource ?

La représentation ou l’abstraction de données la plus importante dans REST est une ressource. Une ressource REST peut être n’importe quel type d’information abstraite, qu’il s’agisse d’un document numérique ou d’un objet non numérique. L’état de la ressource à un instant donné est appelé la représentation de la ressource.

La représentation d’une ressource se compose de trois parties :

Données
Métadonnées
Liens hypermédias

Une API REST se compose d’un ensemble de ressources interconnectées (ou de son modèle de ressources ) accessibles via des URI uniques. Un client peut bénéficier de fonctionnalités flexibles en utilisant les liens vers des ressources et des URI associées dans la réponse. En général, une requête adressée à une API REST prend la forme d’une requête HTTP GET ; les serveurs renvoient souvent leurs réponses au format JSON.

Les méthodes de requête HTTP suivantes permettent d’agir sur les ressources comme indiqué :

GET – Charger une ressource
POST – Créer une nouvelle ressource
PUT – Modifier une ressource existante
DELETE – Supprimer une ressource

Identifiant de la ressource

Dans les styles architecturaux REST, les identifiants de ressources désignent de manière unique chaque ressource impliquée dans les interactions client-serveur.

Hypermédia

Un « type de média », ou représentation d’un format de données, définit la manière dont une ressource doit être traitée. Dans les API REST, tous les types de médias reposent sur JSON et relèvent de l’hypermédia (parfois appelé hypertexte, bien qu’il en diffère légèrement). Un hypermédia est tout contenu comportant des liens vers d’autres médias. Le principe « Hypermédia en tant que moteur de l’état de l’application » (HATEOAS) est ce qui rend l’architecture REST unique.

Remarque : selon Roy Fielding, pour qu’une API soit considérée comme une API REST, elle doit utiliser l’hypermédia. Cependant, de nombreux concepteurs d’API qualifient aujourd’hui leurs API de « REST[ful] » par effet de mode, même si elles n’utilisent ni hypermédia ni hypertexte.

Auto-descriptif

Les représentations des ressources se veulent auto-descriptives, ce qui signifie que l’API se décrit elle-même dans son propre contexte. Grâce à ces représentations auto-descriptives, le client n’a pas besoin de connaître la catégorie à laquelle appartient une ressource et agit plutôt en fonction du type de média associé à celle-ci.

Avantages des API REST

Aujourd’hui, la plupart des entreprises utilisent des API développées en interne et des API tierces pour assurer la communication entre des applications qui fournissent des fonctionnalités de base, innovantes et essentielles. La majorité de ces API sont des API REST, car les normes de communication spécifiques imposées par REST permettent un échange d’informations sécurisé, efficace et fiable. Les API REST peuvent également fonctionner avec n’importe quel protocole.

Les API REST sont également sécurisées, car le service web RESTful authentifie les requêtes avant d’envoyer une réponse. Pour vérifier l’identité des utilisateurs, les API REST utilisent l’authentification HTTP (à la fois Basic et Bearer Token), des clés d’API et OAuth pour l’accès par connexion.

Les API REST présentent également les avantages suivants :

Évolutivité du système – Les API REST peuvent évoluer efficacement, car REST optimise les interactions entre le client et le serveur. La contrainte RESTful d’absence d’état réduit la charge du serveur, car celui-ci n’a pas à enregistrer d’informations provenant de requêtes précédentes ou les concernant. De plus, la mise en cache réduit le nombre d’interactions client-serveur susceptibles de créer des goulots d’étranglement. Il en résulte des API évolutives et hautement performantes.
Flexibilité pour les développeurs – De nombreuses applications d’entreprise doivent communiquer avec des API internes ou tierces. Les services web RESTful permettent de séparer le client du serveur, afin que chacun puisse évoluer indépendamment.
Indépendance technologique – Les API REST restent indépendantes du langage de programmation et du framework utilisés pour développer les applications correspondantes. Les applications clientes et serveurs n’ont pas besoin d’utiliser le même langage ni le même framework, et ceux-ci peuvent changer sans affecter la conception de l’API ni le processus de communication.

API REST ou GraphQL

Bien que REST reste l’architecture la plus populaire pour connecter les applications clientes et serveurs, GraphQL (développé par Facebook en 2012 et publié en open source en 2015) a été conçu comme une alternative à REST. Les API GraphQL sont plus efficaces que les API REST, car toutes les données nécessaires sont demandées en une seule requête et sous une forme standardisée. REST reste toutefois plus performant dans certains domaines. GraphQL présente une courbe d’apprentissage abrupte et se prête beaucoup moins à la mise en cache que REST. De plus, les applications reposent souvent sur des ressources et ne nécessitent pas de langage de requête comme GraphQL. Cela étant, chaque modèle présente des avantages et des inconvénients, et les organisations peuvent choisir d’utiliser les deux.

Comment NGINX peut-il vous aider ?

La flexibilité des API REST constitue indéniablement un avantage. Toutefois, une trop grande flexibilité peut également conduire à la conception d’une API potentiellement lente ou défaillante. C’est pourquoi de nombreux développeurs choisissent de publier et de gérer leurs API, ainsi que de générer leur documentation, à l’aide de la spécification OpenAPI.

API Connectivity Manager, qui fait partie de F5 NGINX Management Suite, prend en charge la spécification OpenAPI pour les API REST. API Connectivity Manager a été conçu en plaçant l’expérience des développeurs d’API au cœur de sa conception. Il s’agit d’une solution légère et cloud native de gestion des API, qui s’intègre de manière transparente pour publier des API sur le portail des développeurs et la passerelle API.

Commencez un essai gratuit de 30 jours de NGINX Management Suite, qui comprend API Connectivity Manager et Instance Manager.

Contenu associé