Différences entre les API et la messagerie pour la communication entre les applications

Phil Wilkins | Évangéliste du développement cloud chez Oracle | Décembre 2022

Les logiciels doivent communiquer avec d'autres logiciels. Parfois, le logiciel d'une partie d'une application doit envoyer des requêtes à des services ou échanger des données avec une autre partie de l'application. Dans d'autres cas, c'est l'application qui doit envoyer des requêtes à des services ou échanger des données avec une application entièrement différente.

Deux mécanismes classiques sont utilisés pour ces types de communication : les interfaces de programmation d'applications (API) et les messages.

Les différences entre les API et les messages peuvent parfois se révéler déroutantes. C'est parce que les termes sont régulièrement employés de manière ambiguë. L'acronyme « API » a une signification explicite, mais, pour des raisons que nous expliquerons ci-dessous, ce terme a pris plusieurs significations différentes. Les messageries sont un concept souvent très vague qui couvre presque toutes les communications de système à système. Par conséquent, clarifions ce que signifient réellement les API et les messageries.

Définition détaillée des API

Pour le dire simplement, une API est le contrat qui définit comment un logiciel peut recevoir des requêtes d'un service et répondre aux requêtes de services. Les développeurs du logiciel établissent ce contrat.

Simple, non ? Mais seulement en apparence. En pratique, la signification implicite du terme « API » peut changer en fonction du sujet de la conversation. Si nous décortiquons l'acronyme, une API concerne l'interface ou le « contrat » qui régit la manière dont un logiciel peut interagir avec un autre logiciel. Parfois, la conversation sur une API se concentre sur ses définitions architecturales de haut niveau, mais elle peut devenir beaucoup plus précise et pragmatique quand les développeurs évoquent la manière d'implémenter cette API.

Certains livres et articles utilisent l'analogie d'une porte pour aborder ce concept. Les caractéristiques de l'API décrivent la porte. Par exemple, il peut s'agir de la porte d'un supermarché qui s'ouvre automatiquement ou de la porte du coffre ultra sécurisé d'une banque. Le contrat d'une application, c'est-à-dire les caractéristiques de la porte, doit permettre de prendre en compte des points suivants :

Que fait l'API, à un niveau élevé ? Dans l'analogie de la porte, est-elle ouverte sans que l'utilisateur n'ait à toucher quoi que ce soit (porte de magasin de courses) ou contrôle-t-elle l'accès et protège-t-elle ce qui se trouve derrière la porte (coffre de banque) ?
Quelles charges utiles (données transmises) le logiciel devra-t-il prendre en charge ? Par exemple, le logiciel peut, quand il reçoit un numéro de compte bancaire et une autorisation de sécurité, renvoyer le solde de ce compte.
Quelles données doivent être échangées pour exécuter ce service ? Par exemple, il est important de définir exactement à quoi ressemble un numéro de compte ainsi qu'une autorisation de sécurité valides et de définir le contenu de la réponse. Ces détails sont importants ici, car toute ambiguïté peut être source d'erreurs.
Quelle est l'adresse de la porte ? Cela signifie généralement comment l'URI (Universal Resource Identifier) de la demande est formé. Comment le demandeur parle-t-il réellement à l'API ?
Quels protocoles seront utilisés pour communiquer ? Il peut s'agir de technologies connues, telles que HTTP et FTP, ou des protocoles spéciaux, tels que STOMP et QUIC.
Quelles conditions l'utilisateur de l'API doit-il respecter ? Il peut s'agir du chiffrement, d'une fréquence limitée à laquelle les API peuvent être appelées ou de mécanismes de refacturation pour les services commerciaux.
Quelles sont les promesses de l'API ? Il peut s'agir de garanties de niveau de service pour l'API, de sorte qu'une demande soit confirmée ou exécutée au cours d'une période spécifique.

Définition de la messagerie dans le cadre du développement d'applications

Alors que les API définissent les conditions d'envoi et de réception de demandes de service par le logiciel, la messagerie est le processus d'envoi d'informations d'un système à un autre. Le mot-clé est processus.

On peut l'envisager comme suit.

La messagerie fait référence au processus de transmission d'une partie d'informations (le message) du demandeur de service au fournisseur de service (souvent à l'aide d'un tiers appelé courtier).

Pour utiliser une analogie du monde réel, pensez à l'envoi d'un texto à un client. Le prestataire de services doit connaître le numéro de téléphone du destinataire afin que l'opérateur mobile puisse transmettre le message. Toutefois, pour le transporteur, le contenu de la charge utile importe peu. Le transporteur n'a pas besoin de savoir si votre texto est en anglais, en espagnol ou en japonais ou encore s'il contient un emoji.
La messagerie fait référence à toutes les actions en arrière-plan permettant d'envoyer ce message de l'expéditeur au client.

Vous et votre client n'avez pas besoin de comprendre comment fonctionne le processus de messagerie. Vous partez du principe que les opérateurs et les fabricants de smartphones travaillent correctement. De même, l'opérateur n'a pas besoin de comprendre la charge utile. Il doit simplement la livrer à la bonne personne sans altération.

Il convient de rappeler que la plupart des plateformes de messagerie ne se préoccupent pas de la charge utile tant qu'elle répond aux contraintes technologiques. Pour revenir à notre analogie, les smartphones et les opérateurs mobiles ne se soucient pas si votre texte est anglais ou un emoji.

Découvrez en détail la composition des API, plateformes d'API et gestion des API.

Les API et la messagerie fonctionnent ensemble dans les systèmes d'entreprise

Ces systèmes sont conçus à partir de plusieurs processus exécutables distincts et nécessitent par conséquent une communication interprocessus (IPC). Dans ce cas, la communication pour effectuer une transaction peut se révéler complexe, car elle nécessite de nombreux appels d'API avec beaucoup de données strictement formatées. Ces transactions doivent être soigneusement orchestrées et exécutées dans le bon ordre pour répondre aux besoins de l'entreprise.

Prenons l'exemple d'une commande d'achat client. Le processus devra accéder à la base de données des clients, interroger la base de données des stocks, le système comptable, un système de génération de factures et le système de facturation par carte de crédit, ajuster le stock et le compte client, créer une requête pour l'entrepôt et générer une demande d'expédition. Toutes ces étapes doivent être effectuées correctement et dans le bon ordre.

Auparavant, ces interactions étaient effectuées à l'aide d'un stockage partagé, comme un système de fichiers ou une base de données. Toutefois, dans des systèmes d'entreprise plus modernes, les processus peuvent communiquer directement les uns avec les autres, ce qui accélère le processus et supprime les problèmes (par exemple, lorsque le stock pour votre commande a déjà été alloué lors de commandes précédentes).

Comportement synchrone et asynchrone

Nous pouvons différencier les communications de nature synchrone et asynchrone. Dans une communication synchrone, toutes les parties doivent être présentes et pouvoir répondre. Pour notre exemple de commande, les systèmes impliqués dans les paiements électroniques doivent être disponibles en vue d'une interaction en temps réel. Dans d'autres cas, la communication peut être asynchrone, ce qui permet aux parties des systèmes qui souhaitent communiquer de ne pas avoir à être présentes au même moment. C'est ainsi que cela fonctionne lorsque nous échangeons des e-mails. Pour qu'une communication fonctionne de manière asynchrone, nous avons besoin d'un intermédiaire qui transmet les informations.

Ces systèmes complexes de messagerie d'entreprise prennent différentes formes :

Bus de service. Le bus de service fait le pont entre les différents processus et les orchestre, comme c'est le cas dans la transaction complexe exposée ci-dessus. Les systèmes de bus de services intègrent généralement des fonctionnalités à valeur ajoutée, telles que la possibilité de traduire des charges utiles d'un format à un autre (de l'anglais vers le français dans notre analogie de messagerie texte), d'acheminer des messages en fonction du contenu du message, ou même de prendre des décisions en fonction de l'état de la transaction complexe. Par exemple, les tâches A et B peuvent être exécutées en parallèle. Ensuite, la tâche C est effectuée si la tâche B se termine correctement. Si la tâche B échoue, c'est la tâche D qui s'exécute. Si la tâche D vient à échouer, une intervention humaine est prévue.

La messagerie par bus de services est parfois décrite comme utilisant un canal de communication intelligent, en raison de cette intelligence supplémentaire en termes de routage et de planification de messages dans le « canal » entre les fournisseurs et les consommateurs. On parle aussi d'orchestration.

Le fournisseur de messages appelle le bus de services avec un message. Ensuite, le bus de services achemine le message vers les consommateurs. Pendant le routage, le message peut être soumis à une logique de transformation et à un filtrage.

Un synonyme de « bus de services » est bus de messages. À leur genèse, avant que ces technologies ne deviennent des solutions d'architecture orientée service (SOA), il y avait des différences entre les bus de messages et les bus de services. Aujourd'hui, il n'y a pas de réelles différences. En fait, le terme est de plus en plus souvent raccourci à simplement bus.
Services Web : Au sens large du terme, les services Web représentent des communications synchrones directes entre deux processus, généralement à l'aide des protocoles TCP et HTTP (ou des variations, telles que HTTPS et HTTP/2). Le consommateur et le client sont reliés par des connexions point à point (bien qu'il soit courant que l'extrémité du fournisseur prenne en charge plusieurs connexions client simultanées). Il peut y avoir des mandataires (par exemple, des pare-feu réseau, des passerelles d'API et des caches Web) ainsi que des intermédiaires réseau (commutateurs et routeurs) entre les deux processus, mais ni le fournisseur ni le consommateur ne s'en rend compte.
Le fournisseur de messages communique directement avec le consommateur. Le processus de transmission dépend de la disponibilité des deux parties.
Courtiers de messages : Les courtiers de messages sont des intermédiaires entre le fournisseur de messages et le consommateur de messages, et partages des similitudes avec les bus de services et les services Web.

Les courtiers se trouvent entre l'expéditeur et les destinataires des messages et reçoivent le message en cours de communication et le stockent jusqu'à ce que les destinataires l'aient consommé. Cela signifie que le message peut être transmis sans que l'expéditeur ait à se soucier de la disponibilité immédiate du destinataire. Par conséquent, ce type de communication est souvent décrit comme asynchrone ou « fire and forget », car vous savez que le message sera livré à un moment ou à un autre, tant que le courtier reste opérationnel.

La similitude avec les services Web provient du fait que la connexion entre le client et le courtier est représentée sous la forme d'une connexion point à point, alors que le gestionnaire de messages est fonctionnellement invisible.

La ressemblance avec un bus de services provient du fait que le courtier offre un service à valeur ajoutée, car qu'il peut conserver les messages reçus jusqu'à ce que les destinataires soient disponibles. Contrairement à un bus de services plus robuste, un courtier de messages dispose d'une logique minimale avec une compréhension de concepts simples. Il peut notamment savoir quelles destinataires peuvent vouloir recevoir un message particulier et ce qu'il convient de faire si la destination ne consomme pas le message à temps.

Une communication par courtage est décrite comme un canal de communication passif. Les courtiers disposent d'une logique minimale et nécessitent que les participants comprennent ce qu'il est nécessaire de faire lorsqu'un message doit être envoyé ou reçu. Ce style est décrit comme une chorégraphie (par opposition à l'orchestration plus intelligente d'un bus de services).

Le fournisseur de messages envoie son message au courtier. Le courtier conserve ensuite le message jusqu'à ce que le ou les consommateurs aient demandé un message ou soient en mesure de le recevoir. Le fournisseur ne dépend pas du consommateur.

Le rôle de la transmission en continu dans la messagerie d'entreprise

Pour cette discussion, la diffusion en continu peut être considérée comme une forme de messagerie plutôt spécialisée, bien que certaines technologies de transmission en continu puissent prendre en charge un élément du traitement des données. Dans ce contexte, la diffusion en continu décrit l'envoi d'un flux continu d'événements via la technologie IPC aux mêmes destinataire(s), que les services Web ou les courtiers de messages implémentent ou non les communications. (Les bus de services sont très rarement utilisés, car le volume de données et leur vitesse sont trop élevés pour nécessiter la logique avancée d'un bus de services.)

Outre l'envoi constant de données dans un flux, la diffusion en continu exige généralement une connectivité quasiment en temps réel ou à faible latence. Ce n'est donc pas surprenant lorsque vous savez que des services tels que Netflix font ce qu'on appelle couramment de la diffusion en continu ou streaming de vidéos. Personne ne voudrait que le contenu vidéo s'arrête et redémarre quand de nouveaux bits de vidéo sont envoyés par le fournisseur ou lorsqu'un courtier de messages transforme la vidéo d'un format à un autre.

Les technologies courantes pour la diffusion en continu de services Web sont les WebSockets, les flux gRPC et les abonnements GraphQL. En ce qui concerne les flux de messages par courtage (à l'aide de technologies telles que Kafka), vous pouvez parfois tirer parti du fonctionnement des courtiers pour examiner une « tranche » des événements transmis. Vous pouvez ainsi plus facilement collecter des informations précieuses, notamment sur le flux lui-même, d'où le terme analyse de flux.

Bien que la logique appliquée dans l'analyse en continu puisse être poussée, le gestionnaire de messages ne prend pas de décision et ne manipule pas les messages. C'est pourquoi les courtiers sont souvent considérés comme passifs. Ces types de fonctions d'analyse de flux sont souvent implémentées à l'aide de technologies telles que Kafka Streams.

Normes pour les API et la messagerie

Les API et les systèmes de messagerie sont simples à décrire de manière générale, mais les détails et les caractéristiques techniques peuvent se révéler très complexes. Il n'y a tout simplement pas de place pour l'ambiguïté. Il s'avère donc véritablement nécessaire de disposer de normes et de documentation précises avec pour objectif la meilleure application de ces normes.

Ce domaine, en particulier pour les API, est en développement depuis plus de dix ans. Le secteur a adopté la spécification OpenAPI pour les API basées sur REST, qui sont une forme de services Web, et probablement les types d'API les plus couramment utilisées dans les logiciels d'entreprise modernes.

Avec les API (et la diffusion en continu), il existe un certain nombre de normes supplémentaires pour définir et décrire les différents aspects des messages et leur transmission. Il s'agit de tampons de protocole (« protocol buffers » ou « Protobuf »en anglais). Ils sont utilisés avec gRPC et, plus récemment, GraphQL, JSON Schema et YAML.

Ces dernières années, le domaine de la messagerie asynchrone est parvenu à s'accorder sur une définition appelée AsyncAPI, qui a adapté les idées de OpenAPI et d'autres normes en constante évolution pour répondre aux nombreuses exigences en matière de messagerie.

Les applications distribuées modernes sont implémentées sous la forme d'un ensemble de services qui sont des logiciels distincts, parfois exécutés sur les mêmes serveurs, parfois pas. Les API permettent à ces logiciels de communiquer entre eux afin d'obtenir des services ou d'échanger des informations. Les systèmes de messagerie fournissent l'infrastructure nécessaire pour faciliter les communications asynchrones ainsi que des intermédiaires intelligents pour les requêtes d'API, ce qui peut être très simple (comme l'envoi de textos sur smartphone) ou extrêmement complexe (comme l'orchestration pour des transactions commerciales complexes en plusieurs étapes). Il ne faut aussi pas perdre de vue les services distribués qui communiquent directement entre eux à l'aide d'API. Heureusement, l'évolution des techniques et des normes permet d'utiliser les API dans tous les domaines, des appels de base de données aux médias diffusée en continu. De plus, ces API et ces normes de messagerie continuent d'évoluer et d'avancer, ce qui accélère, facilite et sécurise la transition vers des architectures logicielles distribuées innovantes.