Qu’est-ce qu’une API (application programming interface ) ?

Les API exposent uniquement les données et les fonctionnalités nécessaires à une interaction spécifique, en gardant cachés les autres détails d'implémentation internes. Cette abstraction protège l'intégrité du système et simplifie la communication entre les composants logiciels.

Il existe de nombreux types d'API (API matérielles et micrologicielles, API de systèmes d'exploitation, API de bibliothèques et de cadres des exigences, API web, etc.) et, de manière générale, elles fonctionnent toutes de la même façon : elles définissent un contrat entre deux logiciels, en spécifiant ce qui peut être demandé et renvoyé.

Fiche explicative centrée sur l'intégration, cet article se concentre principalement sur les API Web (un type d'API qui permet à un logiciel d'effectuer des requêtes sur un réseau, souvent via HTTP), leur fonctionnement, leurs différences et la manière dont elles sont utilisées pour connecter des systèmes, synchroniser des données et automatiser les workflows.

Nous pouvons voir la communication avec les API comme un ensemble de requêtes et de réponses entre un client et un serveur. L’application qui soumet la requête est le client et le serveur fournit la réponse. L’API définit les termes de communication entre eux.

Pour un exemple simple, considérons le traitement des paiements par des tiers. Lorsqu’un utilisateur achète un produit sur un site e-commerce, le site peut proposer l’option « Payer avec PayPal ». Cette fonction repose sur des API pour établir cette connexion.

• Lorsque l’acheteur clique sur le bouton de paiement, un appel d’API est initié. Cette requête est traitée depuis une application vers le serveur web via l’URI (Uniform Resource Identifier) de l’API et inclut un verbe, des en-têtes et parfois un corps. Ensemble, ces éléments précisent ce qui est demandé et comment.
  
  
• Après avoir reçu une requête valide du client, l’API transmet la requête au programme externe ou au serveur Web, dans ce cas, le système de paiement tiers, et renvoie une réponse avec les informations demandées.
  
  
• L’API transfère les données vers l’application à l’origine de la requête, dans ce cas, le site web du produit.

Pour l'utilisateur final, tout cet échange est invisible ; il voit simplement une confirmation de paiement réussie.

Les API existent à tous les niveaux du logiciel, depuis le matériel jusqu'aux services web avec lesquels la plupart des gens interagissent quotidiennement. Dans de nombreuses conversations quotidiennes, l'API est utilisée comme synonyme d'API Web. Mais il existe de nombreux types d'API répondant à différents cas d'utilisation, notamment :

• Les API matérielles et logicielles permettent aux logiciels de communiquer avec les composants physiques d'un appareil, tels que les processeurs et les capteurs.
  
  
• Les API du système d’exploitation permettent aux logiciels de communiquer avec les systèmes d’exploitation pour des services tels que la gestion des fichiers, des processus et de la mémoire.
  
  
• Les API des bibliothèques et des cadres des exigences exposent du code préécrit (fonctions, méthodes et hooks) avec lequel les développeurs interagissent directement dans leurs applications sans passer par le réseau. 
  
  
• Les API de base de données permettent aux logiciels de communiquer avec, de manipuler et d'extraire les informations stockées dans une base de données.
  
  
• Les API Web permettent aux logiciels d'effectuer des requêtes sur un réseau, souvent via HTTP. Il s'agit d'un type d'API distante, facilitant la communication et la manipulation des ressources entre différentes machines, plutôt qu'entre un seul appareil.

*Il convient de noter que certains systèmes plus anciens exposent directement des protocoles réseau — tels que FTP, SMTP et SSH — comme interface d’intégration. Techniquement, ces API correspondent à une définition large, bien qu'elles soient catégorisées selon leur mode de communication plutôt que selon ce avec quoi elles interagissent, et qu'elles soient moins pertinentes dans le cadre d'une discussion axée sur l'intégration.

Les API Web sont les plus courantes pour l'intégration. Contrairement aux autres types d’API mentionnés ci-dessus, ils sont conçus pour la communication entre des applications distinctes via un réseau.

REST est aujourd'hui le style architectural dominant pour les API web. Les API REST, également appelées APIs RESTful, reposent sur six contraintes architecturales directrices définies pour la première fois par Roy Fielding pour la création de services web évolutifs, flexibles et découplés.

REST présente les données sous forme de ressources, et les API REST utilisent des méthodes HTTP telles que GET, POST, PUT, PATCH et DELETE pour interagir avec ces ressources. Chaque ressource est identifiée par un URI unique, communément appelé point de terminaison. C’est l’adresse spécifique à laquelle le client envoie une requête API.

REST est défini par les contraintes suivantes :

• Interface uniforme - Crée des règles de communication standardisées : toutes les requêtes pour une même ressource doivent être identiques. Chaque ressource doit avoir une URI.
  
  
• Séparation client/serveur - Les applications client et serveur doivent pouvoir évoluer séparément, sans aucune dépendance. La seule information dont dispose le client est l’URI de la ressource.
  
  
• État sans état :le serveur ne magasin l’état de la session entre les requêtes. Chaque demande est autonome et doit inclure toutes les informations nécessaires à son traitement.
  
  
• Mise en cache - Toutes les ressources doivent être mises en cache lorsque cela est possible, et le serveur doit déclarer ces ressources comme étant mises en cache.
  
  
• Architecture système en couches : comme chaque requête REST est autonome, le client n’a pas besoin de savoir s’il communique avec le serveur d’origine ou avec un serveur intermédiaire. REST est donc parfaitement adapté aux API publiques destinées à de nombreux clients.
  
  
• Code à la demande (facultatif) : les API REST renvoient généralement des données. Cette dernière contrainte (la seule contrainte facultative) permet de renvoyer un code exécutable, tel que JavaScript, que le client peut exécuter en cas de besoin.

Pour une explication plus complète des principes REST, cliquez ici.

SOAP est un protocole de messagerie XML dont les normes sont strictes en matière de structure et de transmission des messages. Contrairement aux API REST, qui fonctionnent en pratique presque exclusivement sur HTTP, SOAP est indépendant du transport. Il peut fonctionner via HTTP, SMTP et d'autres protocoles, ce qui le rend plus flexible dans les environnements d'entreprise où HTTP n'est pas toujours le protocole sous-jacent.

Les messages SOAP ont une structure rigide qui spécifie comment le message doit être traité, ce qui les rend plus verbeux que REST, mais aussi plus standardisés. Les normes formelles, la gestion des erreurs intégrée et les spécifications de sécurité rigides de SOAP restent précieuses et justifient son utilisation continue aujourd’hui dans des secteurs tels que la finance et la santé.

RPC est antérieur aux API Web et possède des implémentations à la fois anciennes et modernes. RPC, parfois appelé appel de sous-routine ou appel de fonction, permet à une application d'exécuter une fonction ou une méthode sur un serveur distant comme si elle était locale. RPC est organisé autour d'actions plutôt que de ressources. Plutôt que des URI individuelles pour chaque ressource, les API RPC exposent généralement un point de terminaison unique et spécifient l'action dans la charge utile de la requête.

Prédécesseur direct du JSON-RPC, XML-RPC utilise le XML pour encoder ses appels et ses réponses. Il est plus ancien que SOAP mais plus simple, ce qui facilite sa mise en œuvre, même si la verbosité du XML le rend plus lourd que les alternatives basées sur JSON. Il s'agit essentiellement d'un ancêtre direct de JSON-RPC.

JSON-RPC fonctionne de la même manière que XML-RPC, mais utilise JSON au lieu de XML. JSON est plus compact et plus facile à analyser que XML, ce qui rend JSON-RPC plus léger et plus lisible que son prédécesseur.

gRPC est le niveau moderne et haute performance de la famille RPC. Initialement développé par Google, il est désormais géré en tant que projet open source. Alors que les anciennes implémentations RPC utilisent des formats textuels, gRPC utilise Protocol Buffers (ou Profobuf), un format de sérialisation binaire qui produit des messages plus petits et plus rapides que JSON ou XML.

Il fonctionne également sur HTTP/2 plutôt que sur HTTP/1.1, ajoutant d’autres avantages en termes de performances. gRPC est couramment utilisé pour la communication interne de microservice et prend en charge le streaming bidirectionnel, ce qui en fait un excellent choix pour les flux de données en temps réel.

GraphQL est un langage de requête open source et un environnement d’exécution côté serveur développé par Facebook en 2012 pour faciliter la récupération des ressources. Il est conçu pour éliminer la sur-récupération (réception de plus de données que nécessaire) et la sous-récupération (nécessité de plusieurs requêtes pour recevoir les données nécessaires) en permettant aux clients de spécifier exactement les données qu'ils souhaitent. GraphQL utilise un point de terminaison unique via lequel les clients peuvent interroger plusieurs ressources, les résultats étant renvoyés en une seule réponse.

Bien que très flexible, GraphQL est plus complexe que REST et est principalement utilisé dans des environnements complexes où les exigences en matière de données client varient considérablement.

Pour une comparaison plus approfondie entre REST et GraphQL, cliquez ici.

Les API mentionnées précédemment suivent toutes un modèle requête/réponse initié par le client. Deux exceptions importantes méritent d'être signalées dans un contexte d'intégration :

• Les WebSockets (API WebSocket) maintiennent une connexion bidirectionnelle persistante, adaptée aux cas d'utilisation en temps réel, tels que les flux de données en direct.
  
  
• Les webhooks inversent complètement le modèle : au lieu que le client n'initie une demande, le serveur envoie des push notifications au client lorsqu'un événement précis se produit.

Les API publiques sont entièrement exposées sur Internet et sont accessibles à tout développeur ou entreprise, généralement sans restriction ou avec des restrictions minimales. Les développeurs sont peut-être tenus de se procurer une clé d’API, mais autrement, il n’y a pas beaucoup à faire pour travailler avec ces API. Ils sont conçus pour encourager l’intégration externe et le développement par des tiers.

*À ne pas confondre avec la « spécification OpenAPI (OAS) », dont vous pouvez en savoir plus. 

Les API privées ne sont pas accessibles au public et ne sont accessibles qu'au sein d'une entreprise définie. Ils sont souvent isolés sur des réseaux privés et nécessitent une authentification stricte pour l’accès. Les entreprises utilisent couramment de telles API pour connecter des systèmes logiciels internes.

Du point de vue de l'accès, les API partenaires se situent entre les API publiques et privées, car elles ne sont accessibles qu'à un groupe spécifique de partenaires commerciaux autorisés. Bien qu'elles soient accessibles via Internet, elles ne sont pas ouvertes au public et l'accès est réservé aux utilisateurs autorisés. Les API partenaires sont utilisées pour le partage de données B2B ou la monétisation des flux de données, et leur utilisation est souvent régie par des accords partenaires spécifiques. 

*Les API composites sont parfois incluses dans cette répartition des types d'accès, mais il est préférable de les comprendre comme un modèle architectural plutôt que comme un niveau d'accès. Les API composites combinent des appels d’API et peuvent être publiques, privées ou partenaires. Elles sont abordées plus en détail dans la section consacrée aux API et aux microservices.

La conception d’API est le processus de prise de décision qui détermine comment une API expose les données et les fonctionnalités. Lors du processus de conception, les équipes décident des protocoles et des styles d’architecture que l’API utilisera, établissent des conventions cohérentes pour la dénomination, les structures de réponse et la gestion des erreurs, décident comment l’accès sera authentifié et autorisé, et définissent une stratégie de gestion des versions pour gérer les ruptures. Ces décisions, parmi tant d'autres, déterminent le fonctionnement d'une API et la manière dont les développeurs interagissent avec elle.

Il s'agit essentiellement d'un processus qui commence par des questions comme « Comment cette API sera-t-elle utilisée ? » et qui se poursuit par l'élaboration d'un schéma directeur pour les API qui réponde aux besoins de l'entreprise.

Les politiques de gouvernance des API d’une entreprise influencent souvent la conception des API. La gouvernance des API désigne l'ensemble complet de normes, de politiques et de pratiques qui orientent la manière dont une entreprise développe, déploie et utilise ses API. Une conception efficace des API permet de produire des API qui respectent ces politiques prédéterminées.

La documentation d'une API est comme un manuel d'instructions techniques qui fournit des informations sur une API, telles que les protocoles pris en charge, les langages et les méthodes d'authentification, des extraits de code, des définitions structurelles et d'autres informations nécessaires aux développeurs pour travailler avec une API. Une documentation complète et à jour sur les API favorise une meilleure expérience des API pour les développeurs et favorise l’adoption, l’intégration et la gestion des API.

API-first (ou API-Design first) est une approche de développement logiciel dans laquelle les API sont considérées comme la base d'une application, conçues avant que le code de l'application ne soit écrit. Plutôt que de commencer par la logique métier du backend et la structure de la base de données, les Entreprises définissent d'abord le contrat, souvent à l'aide d'une spécification d'API telle qu'OpenAPI, puis construisent le reste de l'application en fonction de celui-ci.

C'est une approche privilégiée par les entreprises fortement intégrées, appréciée pour son évolutivité, sa fiabilité et sa cohérence : l'API est la source de vérité, et tous les consommateurs — applications web et mobiles, appareils Internet des objets (IdO), applications et modèles d'IA et autres systèmes — interagissent avec la même couche API plutôt qu'avec des intégrations sur mesure.

Certaines entreprises considèrent la conception d’API d’abord et l’API d’abord comme des approches distinctes, cette dernière étant une fonction plus large et à l’échelle de l’entreprise qui considère les API comme des produits eux-mêmes, avec leurs propres cycles de vie, chefs de produit et feuilles de route.

Les microservices sont un style d’architecture qui divise une application en services indépendants plus petits. Ces services communiquent via des API, souvent un mélange de protocoles et de styles : par exemple, les API REST pour les services externes, gRPC pour la communication interne entre services et les webhooks pour les flux événementiels. Une architecture de microservices offre aux développeurs la flexibilité de choisir le cadre des exigences le mieux adapté à un service particulier.

Il permet également aux développeurs de tester, déployer, mettre à jour, intégrer, maintenir et faire évoluer des services indépendamment les uns des autres. L’isolation des pannes est simplifiée — la défaillance d’un seul composant n’entraîne pas le plantage de toute l’application — et, comme les services sont faiblement couplés, l’implémentation interne peut changer sans rupture d’intégration.

Un problème courant des microservices est ce qu’on appelle le problème du « front-end bavard ». Dans une application traditionnelle, les données résident dans une base de données et un client peut interroger cette base de données avec un seul appel. Dans les microservices, les données sont réparties sur de nombreux services, ce qui peut nécessiter qu’un client communique avec des dizaines de services, via des dizaines de requêtes distinctes, pour obtenir les données dont il a besoin. Les API composites résolvent ce problème en présentant un point de terminaison unifié qui sert de couche d’orchestration, en répondant à une requête client, en communiquant avec divers services back-end pour rassembler les données demandées et en les renvoyant au client dans une seule charge utile.

Les API composites évitent aux clients de devoir effectuer plusieurs appels aller-retour pour une seule opération. Ils masquent également la complexité du système interne : le client n’a pas besoin de savoir quel microservice gère quelles données, mais seulement comment atteindre le point de terminaison composite. De plus, ils peuvent réduire la latence, car un seul appel reposant sur la communication interne d’un microservice est généralement plus rapide que plusieurs appels aller-retour sur un réseau externe.

Malgré tous leurs avantages, les architectures de microservices étendent la surface des API et ajoutent de la complexité, soulignant l'importance d'un API Management robuste.

API Management est le processus de publication, de sécurisation, de contrôle et de surveillance des API tout au long de leur cycle de vie. Ce travail est généralement centralisé via une plateforme de gestion des API qui aide les entreprises à appliquer des politiques cohérentes sur toutes leurs API. Beaucoup de ces plateformes incluent également des outils de conception et de documentation, bien que cette section se concentre sur le rôle opérationnel de la direction.

La gestion de l'API Management comprend la supervision de :

Une API Gateway est une couche logicielle qui offre un point d’entrée unique permettant aux clients d’accéder à plusieurs services backend. Ils évitent aux clients d'avoir à comprendre la complexité de l'architecture de la passerelle ou à interagir avec celle-ci et sont utilisés pour maîtriser la prolifération des API créées par des microservices.

Les fonctions clés incluent le routage, l’authentification, la limitation de débit et la surveillance. Les passerelles peuvent également gérer l'agrégation des requêtes, ce qui en fait un lieu courant pour implémenter des API composites.

La sécurité des API est un ensemble de pratiques et de procédures qui protègent les API et les données qu’elles transmettent contre les utilisations abusives, les attaques de bots malveillants et autres menaces de cybersécurité.  La sécurité de l’API inclut l’authentification (vérification de l’identité de l’utilisateur), l’autorisation (déterminer ce qu’il est autorisé à faire), le chiffrement, la validation des entrées et plus encore. Les technologies de sécurité courantes incluent les clés API et OpenID Connect (ODIC) pour l’authentification et OAuth pour l’autorisation. Une posture de sécurité des API renforcée permet de garantir que seuls les utilisateurs et les applications autorisés accèdent aux API. 

La limitation du débit et la régulation contrôlent le volume et le flux des requêtes API afin de maintenir la stabilité et la disponibilité des systèmes. La limitation de débit limite le nombre d’appels qu’un client peut effectuer dans une période spécifiée, et la limitation de vitesse gère le volume d’appels qu’un système accepte, généralement en ralentissant ou en mettant en file d’attente les requêtes. Les limites de débit ont également une fonction commerciale, permettant aux entreprises d'appliquer des niveaux d'utilisation pour les API payantes.

Bien qu'il s'agisse principalement de préoccupations opérationnelles, la limitation et la limitation de débit jouent toutes deux un rôle secondaire en matière de sécurité, contribuant à contrecarrer les attaques par déni de service et par bourrage d'identifiants.

API Management applique la stratégie de versionnement définie dans la conception. Les plateformes de gestion permettent aux entreprises de router le trafic vers la bonne version de l’API, d’exécuter plusieurs versions simultanément et de gérer la dépréciation des versions plus anciennes. Cela permet aux équipes de déployer des mises à jour et de nouvelles versions, y compris les modifications les plus importantes, tout en laissant le temps aux intégrations existantes de migrer sans interruption.

Les API constituent le tissu conjonctif entre les systèmes, les services et les partenaires de l'entreprise, et il est essentiel de comprendre leur fonctionnement. Une API défaillante peut entraîner des problèmes pour toutes les intégrations qui en dépendent ; la surveillance et l'observabilité aident les équipes à détecter et à diagnostiquer ces problèmes avant qu'ils ne se répercutent sur les systèmes connectés.

La surveillance des API permet de suivre les performances, la disponibilité, les fonctionnalités et l’utilisation des API. Elle émet des alertes lorsque des indicateurs tels que la latence ou les taux d’erreur dépassent des seuils prédéfinis. L'observabilité s'étend au-delà de la surveillance, en utilisant des indicateurs, des journaux et des traces pour acquérir une compréhension plus approfondie de la santé du système et mettre en surface des informations que la surveillance ne signale pas.

Comprendre l’utilisation des API aide les équipes à planifier la capacité, à traiter les menaces potentielles et à respecter les exigences gouvernementales et réglementaires.

Les API connectent les applications, les systèmes et les workflows pour l’échange de données et de services, une fonction souvent appelée intégration des API. Dans la plupart des intégrations modernes, les API sont essentielles à la circulation des informations entre les services et les systèmes.

Voici des cas d’utilisation courants dans les entreprises :

Les API permettent aux équipes d’intégrer des services tiers dans leurs applications et workflows. Par exemple, si une entreprise de sauce piquante souhaite inclure une carte de localisation de magasin sur son site web montrant les détaillants partenaires, elle peut utiliser l’API d’une application de cartographie pour intégrer ces informations sur son site.

Les entreprises utilisent des API pour partager des données et des services avec des partenaires, fournisseurs et clients. Une entreprise de logistique peut utiliser une API pour exposer les informations de suivi des commandes afin que les détaillants puissent les intégrer à leurs propres systèmes.

Les organisations utilisent des API pour faciliter l'échange de données entre les systèmes de l'entreprise, tels que les plateformes de gestion de la relation client (CRM) et de planification des ressources d'entreprise (ERP). Si une adresse client est mise à jour sur une plateforme CRM, ce changement peut être automatiquement propagé entre les systèmes connectés.

Les API sont utilisées pour accéder à des outils IA tels que les grands modèles de langage (LLM) et les modèles de machine learning, et pour les intégrer dans les applications et les workflows. Intégration de modèles IA fonctionne comme les autres intégrations tierces : au lieu qu'une équipe ait à créer et à entraîner un modèle complexe en interne, elle peut utiliser une API pour accéder à un modèle externe.

Les agents IA utilisent également des API pour accéder aux services et accomplir des tâches, mais ils fonctionnent différemment des intégrations traditionnelles dans lesquelles un développeur décide à l’avance quelles API appeler et comment les appeler. Les agents IA prennent cette décision à l'exécution et doivent être libres d'analyser un problème, de choisir un outil et de découvrir des solutions à la volée. Ils ont besoin d'une méthode cohérente pour découvrir les outils et comprendre comment les utiliser.

Model Context Protocol (MCP), une norme open source introduite par Anthropic et désormais gouvernée par la Linux Foundation, connecte des modèles IA et agents avec des applications et systèmes externes, comblant ainsi cette lacune. Les serveurs MCP se superposent généralement aux API existantes en tant que « traducteur universel », décrivant les capacités d'un outil de manière standardisée que toute application d'IA compatible MCP peut utiliser. Plutôt que de créer une intégration personnalisée entre chaque application d'IA et chaque outil, les développeurs peuvent créer un serveur MCP pour un outil particulier et le rendre disponible à tout agent compatible. Le MCP est souvent comparé à un port USB-C pour les applications d'IA, car il offre un connecteur standard au lieu de plusieurs connecteurs personnalisés.

Les applications mobiles et web utilisent des API pour communiquer avec leurs serveurs et récupérer des données ou déclencher des actions sans jamais accéder directement aux bases de données ou à la logique métier. Une entreprise peut construire la fonctionnalité backend une seule fois et utiliser des API pour servir les clients web, iOS et Android. De nouveaux canaux peuvent être ajoutés sans avoir à reconstruire le backend.

Certaines entreprises vont encore plus loin en adoptant une approche de services Backend pour le Frontend qui ajoute des couches légères spécifiques au client au-dessus des API partagées, tout en conservant la logique cœur de métier au même endroit.

Certaines applications ne peuvent pas attendre que les clients demandent des informations. Les API en temps réel et événementielles inversent la relation, en diffusant les informations dès qu'elles changent ou lorsqu'un événement particulier se produit, au lieu d'attendre que les clients demandent des mises à jour à répétition.

Les webhooks notifient les systèmes connectés lors d'événements spécifiques, tandis que les WebSockets et le streaming gRPC maintiennent des connexions continues pour les flux de données permanents. Ensemble, ils alimentent les plateformes de trading financier, les systèmes de chat, les jeux multijoueurs et l’échange de données des capteurs IdO, maintenant les systèmes à jour sans avoir besoin de sondages constants.