Une API, qu'est-ce que c'est ?

Une API (Application Programming Interface) ou interface de programmation d'application est un ensemble de définitions et de protocoles qui facilitent l'assemblage et l'intégration des applications.

Les API permettent à des produits ou services de communiquer avec d'autres produits et services sans connaître les détails de leur mise en œuvre. Leur utilisation peut simplifier le développement d'applications, avec à la clé un gain de temps et d'argent. Dans le cadre de la conception ou de la gestion d'outils et de produits, les API offrent davantage de flexibilité. Elles simplifient aussi la conception, l'administration et l'utilisation, et multiplient les possibilités d'innovation.

On pourrait comparer les API à des contrats, la documentation représentant l'accord entre les parties : si la partie 1 envoie une requête à distance structurée d'une certaine manière, le logiciel de la partie 2 devra répondre selon les conditions définies.

Parce que les API simplifient la façon dont les équipes de développement intègrent de nouveaux composants d'applications à une architecture existante, elles facilitent la collaboration entre les équipes métier et informatiques. Les besoins métier changent souvent rapidement face à l'évolution constante des marchés numériques, où il suffit d'une nouvelle application pour bouleverser tout un secteur. Pour préserver leur compétitivité, les entreprises doivent développer et déployer des services innovants à un rythme soutenu. Pour y parvenir, elles optent pour le développement d'applications cloud-native qui repose sur l'utilisation d'API pour connecter les microservices de l'architecture d'applications.

En plus de simplifier la connexion de l'infrastructure dans le cadre du développement d'applications cloud-native, les API permettent de partager les données avec les clients et d'autres utilisateurs externes. Les API publiques offrent une valeur métier unique, car elles peuvent simplifier et développer les relations avec les partenaires, ainsi que monétiser les données (l'API Google Maps en est un parfait exemple).

Prenons l'exemple d'un distributeur de livres. Il peut mettre à la disposition des librairies qui se fournissent chez lui une application cloud leur permettant de vérifier la disponibilité des livres. Le développement de cette application risque de coûter cher et de durer longtemps. Il faudra aussi gérer les limites de la plateforme et le besoin de maintenance continue.

À la place, le distributeur pourrait fournir une API permettant de vérifier la disponibilité des stocks. Cette approche présente plusieurs avantages :

• Lorsque l'accès aux données passe par une API, les clients ont la possibilité de centraliser les informations sur leur inventaire.
• Le distributeur peut modifier ses systèmes internes sans affecter l'expérience des clients, tant que le comportement de son API ne change pas.
• Avec une API publique, les équipes de développement qui travaillent pour le distributeur, pour les librairies ou pour d'autres entreprises peuvent développer une application permettant aux clients de trouver les livres qui les intéressent. Cette technique peut générer davantage de ventes ou de nouvelles opportunités commerciales.

En bref, les API ouvrent l'accès aux ressources sans dégrader le niveau de contrôle et de sécurité. Il revient à l'entreprise de choisir l'API à utiliser, les ressources à partager et à qui accorder cet accès. La sécurité des API dépend avant tout de leur bonne gestion, qui repose en partie sur l'utilisation d'une passerelle d'API. Pour la connexion aux API et la création des applications utilisant les données ou fonctionnalités qu'elles exposent, l'entreprise peut utiliser une plateforme d'intégration distribuée qui connecte toutes les ressources, notamment les systèmes existants et l'Internet des objets.

L'utilisation d'API accessibles aux partenaires et aux tiers offre certains avantages :

• Gain ou développement de sources de revenus
• Élargissement de la portée de la marque
• Intensification de l'innovation Open Source ou amélioration de l'efficacité grâce au développement et à la collaboration externes

Si cette technologie est particulièrement intéressante, il faut toutefois bien comprendre le rôle des API.

Reprenons l'exemple du distributeur de livres.

Imaginons qu'un partenaire de l'entreprise développe une application qui permet aux clients de trouver les livres qu'ils cherchent dans une librairie. Grâce à cette expérience améliorée, la fréquentation de la librairie (le client du distributeur) augmente, ce qui génère davantage de revenus à partir d'une source existante.

Un tiers peut aussi utiliser une API publique pour développer une application qui donne la possibilité d'acheter des livres directement auprès du distributeur, sans passer par une librairie. Dans ce cas, le distributeur bénéficie d'une nouvelle source de revenus.

Le partage des API peut s'avérer très bénéfique, que ce soit avec une sélection de partenaires ou avec le monde entier. Chaque partenariat fait connaître une marque hors du cadre de ses propres campagnes marketing. En ouvrant l'accès aux technologies, comme ici avec une API publique, les entreprises encouragent les équipes de développement à créer un écosystème d'applications autour de l'API. Plus il y a d'utilisateurs de leurs technologies, plus elles ont accès à des opportunités commerciales.

Les technologies publiques peuvent être à l'origine de résultats aussi inattendus qu'intéressants, qui peuvent même bouleverser des secteurs entiers. Dans le cas de notre distributeur de livres, de nouvelles entreprises, comme un service de location de livres, peuvent transformer radicalement son activité. Les API publiques et de partenaires permettent de profiter des innovations d'une vaste communauté de développement. De nouvelles idées peuvent venir de toutes parts et les entreprises doivent se tenir au courant des changements qui s'opèrent sur leur marché afin de s'y adapter. Les API peuvent les aider à se préparer.

Les API sont apparues au tout début de l'informatique, bien avant les ordinateurs personnels. À cette époque, elles étaient surtout utilisées comme bibliothèques pour les systèmes d'exploitation. Elles résidaient presque toutes en local sur les systèmes qui les exécutaient, même si elles transféraient parfois des messages entre les ordinateurs mainframe. Presque 30 ans plus tard, les API sont sorties de leurs environnements locaux. Au début des années 2000, elles ont commencé à être très utilisées pour l'intégration à distance des données.

Les API distantes interagissent via un réseau de communication. Le terme distant signifie que les ressources dont se sert l'API ne se trouvent pas sur l'ordinateur qui formule la requête. Le réseau de communication le plus fréquemment utilisé étant Internet, la plupart des API respectent les normes du Web. Toutes les API distantes ne sont pas des API web, mais l'inverse est probablement vrai.

En général, les API web passent par le protocole HTTP pour les messages de requête et définissent la structure des réponses. Celles-ci se présentent pour la plupart sous la forme d'un fichier XML ou JSON. Ces deux formats sont les plus courants, car les données qu'ils contiennent sont faciles à manipuler pour les autres applications.

Pour standardiser l'échange d'informations entre des API web toujours plus nombreuses, le protocole SOAP (Simple Object Access Protocol) a été développé. Les API basées sur ce protocole envoient des messages au format XML et reçoivent des requêtes via HTTP ou SMTP. Le protocole SOAP simplifie le partage d'informations pour les applications qui s'exécutent dans des environnements différents ou qui utilisent d'autres langages.

Il existe également la spécification REST (Representational State Transfer). Les API web qui respectent les contraintes de l'architecture REST sont appelées API RESTful. Alors que SOAP est un protocole, REST est un style d'architecture. Aucune norme officielle ne régit les API web RESTful. Selon la définition que propose Roy Fielding dans sa thèse intitulée « Architectural Styles and the Design of Network-based Software Architectures », les API sont RESTful lorsqu'elles respectent les six contraintes spécifiques des systèmes RESTful :

• Architecture client-serveur : une architecture REST se compose de clients, de serveurs et de ressources. Elle traite les requêtes via le protocole HTTP.
• Fonctionnement stateless : les contenus du client ne sont jamais stockés sur le serveur entre les requêtes. Le client conserve les informations sur l'état de la session.
• Mémoire cache : la mise en cache permet d'éviter certaines interactions entre le client et le serveur.
• Système en couches : des couches supplémentaires peuvent gérer les interactions entre le client et le serveur. Ces couches peuvent offrir d'autres fonctions, telles que l'équilibrage de charge, le partage de cache ou la sécurité.
• Code à la demande (facultatif) : les serveurs peuvent enrichir les fonctionnalités d'un client en transférant du code exécutable.
• Interface uniforme : cette contrainte est essentielle pour concevoir des API RESTful. Elle repose sur quatre conditions :
  • Identification des ressources dans les requêtes : les ressources sont identifiées dans les requêtes et séparées des représentations renvoyées au client.
  • Manipulation des ressources dans les représentations : les clients reçoivent des fichiers qui représentent les ressources. Ces représentations doivent contenir suffisamment d'informations pouvant être modifiées ou supprimées.
  • Messages autodescriptifs : chaque message renvoyé doit contenir assez de détails pour décrire la manière dont le client doit traiter les informations.
  • Hypermédia comme moteur de l'état des applications : après avoir accédé à une ressource, le client REST doit être en mesure de découvrir toutes les autres actions disponibles grâce à des hyperliens.

Ces contraintes peuvent sembler difficiles à appliquer, mais elles sont en fait plus simples à utiliser qu'un protocole imposé. C'est pourquoi les API RESTful remplacent peu à peu le protocole SOAP.

Ces dernières années, la spécification OpenAPI est devenue l'une des normes les plus utilisées pour définir les API REST. Elle permet aux équipes de développement d'assembler des interfaces d'API REST faciles à comprendre, dans le langage de leur choix.

Il existe une autre norme d'API qui est aussi couramment utilisée. Il s'agit de GraphQL, un langage de requête et un environnement d'exécution côté serveur qui peut remplacer l'architecture REST. Il vise à fournir aux clients uniquement les données demandées. Utilisée à la place de REST, cette norme permet aux équipes de développement de créer des requêtes qui extraient des données de plusieurs sources avec un seul appel d'API.

En savoir plus sur les différences entre SOAP et REST

Les deux approches architecturales qui utilisent le plus les API distantes sont l'architecture orientée services (SOA) et l'architecture de microservices. La plus ancienne est l'approche SOA. Elle a été développée pour améliorer les applications monolithiques. Elle les allège en fournissant certaines fonctions par le biais d'autres applications faiblement couplées via un modèle d'intégration, comme un ESB (Enterprise Service Bus).

Si l'architecture SOA est plus simple qu'une architecture monolithique sous bien des aspects, elle risque néanmoins d'entraîner des changements en cascade dans l'environnement en cas d'erreur de compréhension au niveau des interactions entre les différents composants. Ce niveau de complexité fait ressurgir certains des problèmes initiaux des applications monolithiques.

Les architectures de microservices utilisent elles aussi des services spécialisés et faiblement couplés. Cependant, elles déstructurent davantage l'architecture traditionnelle. Les services qui composent une architecture de microservices se servent d'une structure de messagerie commune, telle que les API RESTful. Celles-ci leur permettent de communiquer plus facilement, sans convertir les données ni recourir à des couches supplémentaires d'intégration. L'utilisation des API RESTful s'avère particulièrement efficace pour accélérer la distribution des nouvelles fonctions et mises à jour. Chaque service est distinct. Il est possible de remplacer, d'améliorer ou de supprimer chacun d'entre eux sans aucune conséquence sur les autres services. Cette architecture légère permet d'optimiser les ressources cloud ou distribuées et de faire évoluer chaque service de façon dynamique.

En savoir plus sur les architectures SOA

Un webhook est une fonction de rappel basée sur le protocole HTTP. Il permet à deux API d'établir une communication légère et orientée événements. Utilisés par diverses applications web pour réceptionner de petites quantités de données en provenance d'autres applications, les webhooks peuvent également déclencher des workflows d'automatisation dans des environnements GitOps.

On qualifie souvent les webhooks d'API inversées ou d'API « push », car ils confient la communication au serveur au lieu du client. C'est le serveur qui envoie au client une demande HTTP POST unique dès que les données sont disponibles, et non le client qui envoie des requêtes en continu. Malgré leurs surnoms, les webhooks ne sont pas des API. Ces deux systèmes fonctionnent toutefois ensemble. Pour utiliser un webhook, une application doit disposer d'une API. 

En savoir plus sur les webhooks

Le protocole MCP (Model Context Protocol) et les API sont deux méthodes qui permettent de connecter des systèmes distincts. Le protocole MCP n'existerait pas sans les API, sur lesquelles reposent ses fonctionnalités. 

La différence entre ces technologies réside dans leur fonctionnement et leurs objectifs :

• Le protocole MCP connecte les modèles de langage à des outils et données externes. Il alimente des workflows qui s'adaptent et improvisent en temps réel. 
• Les workflows traditionnels d'API suivent un ensemble de règles immuables. Une fois deux systèmes connectés, les interactions sont limitées à des actions spécifiques qu'un développeur programme.

En savoir plus sur les différences entre le protocole MCP et les API