Une API REST est un type d’interface de programmation d’applications (API) conforme au modèle REST (representational state transfer) de représentation des données et de communication entre deux systèmes (un client et un serveur) sur un réseau tel qu’Internet. Les API REST prennent en charge l’échange d’informations entre les applications internes et les applications tierces, et permettent aux entreprises d’intégrer de multiples points d’extrémité dans leur écosystème applicatif.
Remarque : à proprement parler, REST fait référence au modèle et n’est pas un adjectif désignant une API qui y adhère, pour laquelle le terme approprié est RESTful API. Cependant, API REST est l’usage le plus courant et c’est pourquoi il est utilisé dans cet article.
REST, qui comme indiqué signifie representational state transfer, est un style architectural créé par l’informaticien Roy Fielding en 2000. REST offre de la flexibilité aux développeurs, ce qui le rend idéal pour connecter des applications dans des architectures de microservices.
REST définit six contraintes auxquelles les applications et les API doivent se conformer pour être considérées comme RESTful :
Pour en savoir plus sur ces contraintes, consultez Wikipédia.
Une interface uniforme simplifie l’architecture globale du système et améliore la visibilité des interactions. Elle comporte également des exigences spécifiques visant à garantir que les informations sont transférées sous une forme standard.
Quatre contraintes permettent d’uniformiser une interface REST :
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 du client et du serveur d’évoluer de manière autonome. Elle simplifie également la portabilité de l’interface utilisateur du client sur plusieurs plates-formes et l’extensibilité du serveur.
Sur Internet, l’interaction client-serveur se fait par le biais du protocole HTTP.
Dans la communication client-serveur, l’apatridie signifie que le serveur ne stocke aucune information sur le client ou la session établie avec lui. La représentation par le client des informations liées à la session dans chaque message doit permettre au serveur de les comprendre de manière isolée, sans aucun contexte des messages précédents. Cela réduit la charge du serveur, améliorant ainsi les performances des applications volumineuses.
Les clients n’ont pas besoin de savoir (et ne peuvent généralement pas savoir) s’ils sont connectés directement au serveur ou à un intermédiaire tel qu’un proxy inverse ou un équilibreur de charge. Les serveurs intermédiaires permettent d’améliorer l’évolutivité et peuvent être utilisés pour gérer la sécurité de sorte que les serveurs ne soient responsables que de la logique commerciale.
Les clients HTTP et les intermédiaires peuvent mettre en cache les réponses du serveur afin de réduire la charge du serveur et d’augmenter la vitesse de transmission des données aux utilisateurs finaux. Le serveur doit indiquer si une réponse peut être mise en cache ou non, ce qui garantit que les réponses aux demandes ultérieures des utilisateurs finaux sont correctes et à jour (et non potentiellement « périmées »). Étant donné que les clients accèdent à une ressource par son URL, qui est un identifiant unique, le client peut déterminer ce qu’il faut mettre en cache au niveau de la ressource.
Le code à la demande signifie que le serveur peut envoyer un code exécutable pour étendre ou personnaliser temporairement la fonctionnalité du client, ce qui évite au client d’avoir à mettre en œuvre lui-même la fonctionnalité. La contrainte du code à la demande est facultative.
La représentation des données ou l’abstraction la plus importante dans REST est une ressource. Une ressource REST peut être n’importe quel type d’information abstraite, d’un document numérique à un objet non numérique. L’état de la ressource à un moment donné est appelé la représentation de la ressource.
La représentation d’une ressource se compose de trois parties :
Une API REST consiste en un ensemble de ressources interconnectées (ou son modèle de ressources) qui sont accessibles par des URI uniques. Un client peut obtenir une fonctionnalité flexible en établissant des liens vers des ressources et des URI connexes dans la réponse. En général, une demande à une API REST est envoyée sous la forme d’une requête HTTP GET ; les serveurs formatent souvent leurs réponses sous forme JSON.
Les méthodes de requête HTTP suivantes sont utilisées pour agir sur les ressources de la manière indiquée :
Dans les styles architecturaux REST, les identificateurs de ressources désignent de manière unique chaque ressource impliquée dans les interactions client-serveur.
Un « type de média », ou représentation du 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 sont basés sur JSON et sont hypermédias (parfois connus sous le nom d’hypertexte, mais légèrement différents). L’hypermédia est tout élément de contenu comportant des liens vers d’autres médias. L’hypermédia en tant que moteur de l’état de l’application (HATEOAS) est ce qui fait l’originalité de l’architecture REST.
Note : 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 appellent aujourd’hui leurs API « REST[ful] », un terme à la mode, même s’ils n’utilisent pas l’hypermédia/l’hypertexte.
Les représentations de ressources visent à être auto-descriptives, ce qui signifie que l’API se fait comprendre dans son propre contexte. Avec des représentations auto-descriptives, le client n’a pas besoin de savoir à quelle catégorie appartient une ressource et agit plutôt en fonction du type de média associé à la ressource.
Aujourd’hui, la plupart des entreprises utilisent des API développées en interne ou par des tiers pour la communication entre les applications qui fournissent des fonctionnalités de base, innovantes et critiques. 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 parce que le service Web RESTful authentifie les demandes avant d’envoyer une réponse. Pour vérifier l’identité des utilisateurs, les API REST utilisent l’authentification HTTP (à la fois basique et par jeton), les clés API et OAuth pour l’accès à la connexion.
Les API REST présentent d’autres avantages :
Alors que REST demeure l’architecture la plus populaire pour connecter les applications client et serveur, GraphQL (développé par Facebook en 2012 et devenu 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 fois et sous une forme standardisée, mais il y a encore des domaines où REST brille. GraphQL nécessite une courbe d’apprentissage abrupte et est beaucoup moins « cachable » que REST. En outre, les applications sont souvent pilotées par les ressources et ne nécessitent pas un langage de requête comme GraphQL. Cela dit, chaque modèle a ses avantages et ses inconvénients et les organisations peuvent choisir d’utiliser les deux.
La flexibilité des API REST est certainement un avantage, mais une trop grande flexibilité peut également conduire à la conception d’une API potentiellement lente ou défectueuse, c’est pourquoi de nombreux développeurs choisissent de publier, de gérer et de générer la documentation des API à l’aide de la spécification OpenAPI.
API Connectivity Manager, qui fait partie de la suiteF5 NGINX Management, prend en charge la spécification OpenAPI pour les API REST. API Connectivity Manager a été conçu pour répondre aux besoins des développeurs d’API. Il s’agit d’une solution de gestion d’API légère et cloud-native, avec une intégration transparente pour la publication d’API sur le portail des développeurs et la passerelle API.
Démarrez un essai gratuit de 30 jours de la suite NGINX Management, qui comprend API Connectivity Manager et Instance Manager.