Une API REST est un type d' interface de programmation d'application (API) conforme au modèle de transfert d'état représentatif (REST) 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 tierces et permettent aux entreprises d'intégrer plusieurs points de terminaison dans leur écosystème d'applications.
Note: Strictement parlant, 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 API RESTful . Cependant, l'utilisation la plus courante est API REST et est donc utilisée dans cet article.
REST, qui comme mentionné signifie « transfert d'état représentatif » , est un style architectural créé par l'informaticien Roy Fielding en 2000. REST offre une 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 obéir pour être considérées comme RESTful :
Vous pouvez en apprendre davantage sur ces contraintes sur 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 à une interface REST d'être uniforme :
Une architecture client-serveur est composée de clients, de serveurs et de ressources. La séparation de l'interface utilisateur (contrôlée par le client) du stockage de données (contrôlé par le serveur) signifie que les composants client et serveur peuvent évoluer de manière autonome. Il simplifie également la portabilité de l’interface utilisateur client sur plusieurs plates-formes et l’évolutivité du serveur.
Sur Internet, l’interaction client-serveur s’effectue via HTTP.
Dans la communication client-serveur, l’absence d’état 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 provenant des messages précédents. Cela réduit la charge du serveur, améliorant ainsi les performances des applications à volume élevé.
Les clients n’ont pas besoin de savoir (et ne peuvent généralement pas le savoir) s’ils sont connectés directement au serveur ou à un intermédiaire comme un proxy inverse ou un équilibreur de charge. Les serveurs intermédiaires contribuent à améliorer l'évolutivité et peuvent être utilisés pour gérer la sécurité afin que les serveurs soient uniquement responsables de la logique métier.
Les clients HTTP et les intermédiaires peuvent mettre en cache les réponses du serveur pour réduire la charge sur le serveur et augmenter la vitesse de livraison des données aux utilisateurs finaux. Le serveur doit indiquer si une réponse peut être mise en cache ou non, cette dernière garantissant que les réponses aux demandes ultérieures des utilisateurs finaux sont correctes et à jour (et non potentiellement « obsolètes »). É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 du code exécutable pour étendre ou personnaliser temporairement les fonctionnalités du client, éliminant ainsi le besoin pour le client d'implémenter la fonctionnalité lui-même. La contrainte de code à la demande est facultative.
La représentation ou l’abstraction des données 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é représentation de la ressource .
Une représentation de ressource comporte trois parties :
Une API REST se compose d'un assemblage de ressources interconnectées (ou de son modèle de ressources ) qui sont accessibles à des URI uniques. Un client peut obtenir des fonctionnalités flexibles en établissant un lien vers des ressources et des URI associés dans la réponse. En général, une requête adressée à une API REST est envoyée sous la forme d'une requête HTTP GET ; les serveurs formatent souvent leurs réponses au format 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 identifiants 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 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 sont basés sur JSON et sont des hypermédias (parfois appelés, bien que légèrement différents, hypertexte ). L'hypermédia est tout élément de contenu comportant des liens vers d'autres médias. L'hypermédia comme moteur de l'état de l'application (HATEOAS) est ce qui rend l'architecture REST unique.
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 souvent leurs API « REST[ful] » comme un mot à la mode, même s'ils n'utilisent pas d'hypermédia/hypertexte.
Les représentations de ressources visent à être autodescriptives, ce qui signifie que l'API se fait comprendre dans son propre contexte. Avec les représentations autodescriptives, 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 et des API tierces 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 car le service Web RESTful authentifie les demandes avant l’envoi d’une réponse. Pour vérifier l'identité des utilisateurs, les API REST utilisent l'authentification HTTP ( Basic et Bearer Token ), les clés API et OAuth pour l'accès de connexion.
Les autres avantages des API REST incluent :
Alors que REST reste l'architecture la plus populaire pour connecter les applications client et serveur, GraphQL (développé par Facebook en 2012 et 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 dans une seule requête et sous une forme standardisée, mais il existe encore certains domaines dans lesquels REST brille. GraphQL nécessite une courbe d'apprentissage abrupte et est beaucoup moins cachable que REST. De plus, les applications sont souvent pilotées par des ressources et ne nécessitent pas de 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 trop de flexibilité peut également conduire à la conception d'une API potentiellement lente ou cassée, 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 F5 NGINX Management Suite , prend en charge la spécification OpenAPI pour les API REST. API Connectivity Manager a été conçu avec l'expérience du développeur d'API comme cœur. Il s'agit d'une solution de gestion d'API cloud légère 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 NGINX Management Suite , qui comprend API Connectivity Manager et Instance Manager .