Types d'API et comment choisir lequel construire

Les interfaces de programmation d'application, mieux connues sous leur petit nom d'API, libèrent les données pour permettre aux entreprises de connecter systèmes, applications, appareils et ensembles de données. Pour savoir quel type d'API convient le mieux à tel ou tel projet, il faut connaître le cas d'utilisation envisagé, les personnes qui utiliseront ces API ou y accèderont, ainsi que les systèmes et ensembles de données à connecter. Pour que les performances et la gestion des API soient optimales, il faut déterminer quel type d'API convient le mieux afin de concevoir et de construire l'architecture en conséquence.

Types d'API par utilisation

Généralement, les entreprises ne décident pas de créer une API du jour au lendemain. Ce besoin part souvent d'une idée, d'une application, d'une innovation ou d'un cas d'utilisation dont le succès dépend de sa connexion à d'autres systèmes ou ensembles de données.

C'est là que les API entrent en jeu : elles établissent cette connexion entre les systèmes et ensembles de données à intégrer.

Les entreprises utilisent différents types d'API à différentes fins, notamment pour exposer en interne la fonctionnalité d'un système stratégique ou encore pour mettre en place une application mobile orientée client. L'approche de connectivité fondée sur les API de MuleSoft comprend trois catégories d'API :

• Les API système : les API système libèrent les données des systèmes d'enregistrement stratégiques de l'entreprise. Parmi les systèmes stratégiques dont les données peuvent être libérées par les API, on trouve les systèmes ERP, les systèmes de gestion des clients et de la facturation, ainsi que les bases de données propriétaires. 

• Les API de processus : les API de processus interagissent avec les données et les façonnent au sein d'un système unique ou sur plusieurs systèmes, ce qui a l'avantage d'éliminer les silos. Les API de processus constituent un moyen de combiner des données et d'orchestrer plusieurs API système pour atteindre un objectif métier spécifique. La création d'une vue à 360 degré du client, l'exécution des commandes et l'état de l'expédition en sont quelques exemples. 

• Les API d'expérience : les API d'expérience fournissent un contexte aux données et processus libérés et établis à l'aide d'API système et d'API de processus. Les API d'expérience exposent les données destinées à être utilisées par les cibles prévues, comme les applications mobiles, les portails internes de données client, etc.

Types de stratégies de gestion des API

Lorsque vous aurez déterminé le cas d'utilisation pour les API de votre entreprise, vous devrez décider qui pourra y accéder. Généralement, le cas d'utilisation et l'utilisateur prévu vont de pair. Si vous souhaitez, par exemple, faire remonter des données client à l'attention du service des ventes en interne et de vos agents de service client, l'utilisateur final sera alors un employé en interne. 

Voici trois types d'API classés en fonction de leur type de gestion et des utilisateurs qui y accèdent :

API externes

Les API externes sont accessibles par des tiers (développeurs, partenaires, etc.) extérieurs à l'entreprise. Elles facilitent généralement l'accessibilité des données et des services de l'organisation sous forme de libre-service destiné aux développeurs du monde entier qui souhaiteraient créer des applications et des intégrations innovantes.
Prenons comme exemple d'API ouverte, l'API Google Maps dont les fonctionnalités de suivi et de géolocalisation sont utilisées par de nombreuses applications tierces, comme les applications de covoiturage ou de livraison de repas. 

API internes

Les API internes sont diamétralement opposées aux API ouvertes. En effet, les utilisateurs externes ne peuvent pas y accéder, et elles sont uniquement mises à disposition des développeurs en interne. Les API internes facilitent les initiatives touchant l'ensemble de l'entreprise, depuis l'adoption des architectures DevOps et des microservices, jusqu'à la modernisation des systèmes legacy en passant par la transformation digitale. En règle générale, l'utilisation et la réutilisation de ces API améliorent la productivité, l'efficacité et l'agilité des entreprises.Voici un exemple d'API interne réutilisable. Imaginons qu'une équipe de centre d'appels crée une API d'informations client permettant d'accéder à leur nom, à leurs coordonnées, aux informations de leur compte, etc. Cette équipe peut réutiliser l'API dans une application Web ou mobile orientée client. 

API partenaires

Les API partenaires se situent à mi-chemin entre les API internes et externes. Elles sont accessibles par des utilisateurs extérieurs à l'entreprise disposant d'autorisations exclusives. D'ordinaire, cet accès spécial est accordé à des tiers bien spécifiques dans le but de faciliter un partenariat métier stratégique. 

Le partage de données entre deux organismes constitue l'un des cas d'utilisation les plus répandus des API partenaires, comme ce peut être le cas pour les services de santé d'une région et un hôpital de cette même région. L'API partenaire est alors configurée de sorte que chaque organisme puisse accéder aux données nécessaires à l'aide de l'ensemble d'identifiants et de données approprié.

Types de style d'architecture d'API

Autre critère de sélection d'une API : le ou les style(s) d'architecture qui seront utilisés. Il est essentiel de sélectionner un style ou un modèle d'architecture parfaitement adapté à l'utilisation que l'on veut faire de l'API, dans le cas où certaines capacités fonctionnelles sont nécessaires. Cette décision relative à la conception d'une API est souvent prise par des équipes plus techniques. 

Avant de prendre cette décision, il est bon de se faire une idée de l'infrastructure déjà en place : systèmes on-prem ou basés sur le cloud, systèmes et ensembles de données à utiliser, protocoles de sécurité à implémenter et fonctionnalités nécessaires. Dans une conception basée sur les API, ce sont les fonctionnalités et les expériences utilisateurs choisies qui transmettent les changements à l'infrastructure IT legacy et non l'état de cette dernière qui impose les fonctionnalités ou les expériences. 

Il existe différents styles d'architecture pour les API au sein desquels on trouve différents formats de données. Nous avons répertorié ci-dessous les plus connus : 

• REST : REST (Representational State Transfer) est un style d'architecture qui sépare les préoccupations de l'utilisateur d'API du fournisseur d'API grâce à des commandes intégrées au protocole de réseau sous-jacent. Les clients se servent des liens et des formulaires inclus pour exécuter les actions (par exemple, la lecture, la mise à jour, le partage, l'approbation, etc.). Le HTML est l'exemple par excellence de ce style, mais il existe de nombreux formats dédiés aux API (HAL, CollectionJSON, Siren, etc.). Les API REST présentent beaucoup d'avantages, notamment la flexibilité et la possibilité de s'adapter aux formats de données les plus répandus comme, entre autres, JSON et XML.
• RPC : dans le cas des RPC ou Remote Procedure Calls, les développeurs doivent généralement exécuter des blocs spécifiques de code sur un autre système. Les appels de procédure à distance de type RPC sur d'autres systèmes nécessitent généralement l'intervention de développeurs qui doivent nommer ces procédures. RPC est indépendant, ce qui signifie qu'il est pris en charge par de nombreux protocoles, sans toutefois bénéficier des avantages offerts par l'utilisation des fonctionnalités des protocoles natifs (par exemple, la mise en cache). La prolifération des noms de procédures non standard d'une API RPC à une autre est à l'origine d'un couplage étroit entre les utilisateurs d'API et les fournisseurs, une situation qui accable encore les développeurs impliqués dans tous les aspects d'un écosystème d'API orienté RPC. Les modèles d'architecture RPC se retrouvent dans des technologies API répandues comme SOAP, GraphQL et gRPC.
• Orientée événements/de streaming : les API orientées événements, que l'on nomme aussi architectures événementielles, en temps réel, de streaming, asynchrones ou encore push, n'attendent pas qu'un utilisateur d'API fasse appel à elles pour donner une réponse. Au lieu de cela, c'est la survenue d'un événement qui déclenche la réponse. Ces services exposent des événements auxquels les clients peuvent s'inscrire de façon à recevoir des notifications lorsque les valeurs du service changent. Ce style présente une poignée de variations notamment, et sans s'y limiter, les mécanismes réactifs, publish-subscribe, de notification d'événements et CQRS.

Ce modèle d'API convient parfaitement à toutes sortes d'événements. En voici quelques exemples :

• Un nouveau tweet vient d'être publié sur un compte Twitter.
• Un thermomètre à distance vient d'enregistrer un changement de température.
• Un véhicule vient de passer sur un capteur placé dans la chaussée.
• Une caméra de surveillance vient de détecter du mouvement dans son champ de vision.
• Un électrocardiographe vient de détecter un rythme cardiaque irrégulier.
• Une sortie de secours vient d'être ouverte.
• Un détecteur de fumée vient de détecter de la fumée.

De nombreux éléments entrent dans la conception et la gestion d'API efficaces. Le contenu ci-dessus vous fournit un résumé des différentes décisions que les entreprises doivent prendre avant de passer à la conception, au déploiement et à la gestion d'une API. Pour de plus amples informations, téléchargez notre livre blanc sur la connectivité fondée sur les API.