La connectivité pilotée par API est le modèle de conception le plus important auquel l’informatique est confrontée aujourd’hui. C’est la clé de la transformation numérique et d’une stratégie informatique qui ouvre les produits et services d’une organisation à ses consommateurs. Il y a de nombreux aspects à ce modèle, donc dans cet article, je vais mettre quelques locataires clés et quelques idées à partir de cela. Ensuite, j’espère que, par le biais de commentaires et de conversations, je pourrai entamer une discussion et poursuivre avec d’autres articles à l’avenir.
En tant qu’architecte de solution senior dans la pratique API d’EPAM, le changement le plus percutant que nous pouvons apporter est l’adoption de la connectivité pilotée par API. La plupart des organisations ont des API dans une certaine mesure, évoluant souvent à partir d’une approche SOA ou de microservices. Les API sont introduites dans une organisation, une à la fois, de sorte que, à partir de l’évolution naturelle, il y aura de nombreuses API, mais elles ne suivront pas une approche de connectivité basée sur les API. La prochaine étape consiste à suivre cette norme, mais il y a souvent de la résistance, comme dans tous les changements. Cela conduit les organisations sur un chemin point à point de connexion de leurs systèmes, ce qui est un anti-modèle dans le monde des API. C’était comme l’époque des applications client-serveur, qui ont finalement été remplacées par un modèle de conception modèle-vue-contrôleur. La connectivité pilotée par API a un concept similaire. Dans le modèle-vue-contrôleur, les utilisateurs du système se connectent au niveau de la vue, le contrôleur gère l’orchestration et le modèle se connecte aux données.
De même, dans la connectivité pilotée par API, il existe également trois couches ; expérience (vue), processus (contrôleur) et système (modèle). Ces trois couches vous permettent de découpler les consommateurs de votre application via la couche d’expérience et vos systèmes d’enregistrement dans votre couche système. Votre logique métier et votre orchestration se trouvent dans la couche de processus. Il y a de nombreux avantages à cela, comme je vais le décrire ci-dessous. Le schéma suivant montre un exemple de connectivité pilotée par l’API.
1. Couche d’expérience
Vous pouvez appliquer la sécurité à différents consommateurs d’applications en fonction de leur niveau d’expérience. Ces consommateurs peuvent être Web, mobiles et tiers, internes ou externes à votre organisation. Vous pouvez fournir plusieurs politiques de sécurité telles que l’ID client, les certificats, OAuth et plusieurs niveaux SLA en fonction des abonnements. Vous pouvez gérer ces consommateurs en fournissant ou en retirant l’accès à vos applications, en autorisant l’accès et en surveillant ces API pour mesurer les volumes et le débit. Cela facilite également la monétisation de vos produits ou services à ce niveau.
2. Couche de processus
La couche de processus contiendra les capacités de votre entreprise et peut être divisée en différents domaines. Chaque secteur d’activité peut avoir ses propres API définissant le produit ou les services qu’il fournit. Par exemple, vous auriez un ensemble d’API définissant le client, les produits ou la facturation. Ces API au niveau du processus sont accessibles par les consommateurs à partir de la couche d’expérience. En outre, les API de processus peuvent appeler d’autres API au niveau de la couche processus ou peuvent appeler des API au niveau de la couche système, qui fournissent ou mettent à jour les informations de vos systèmes d’enregistrement.
3. Couche système
La couche Système expose les informations de vos différents systèmes d’enregistrement. Ce seront vos anciens systèmes, vos bases de données, les CRM (Customer Relationship Management) comme Salesforce, et les ERP (Enterprise Resource Planning) comme SAP. Par exemple, vous pouvez ajouter des files d’attente, des caches, des délais d’attente et des disjoncteurs à cette couche si vous rencontrez des problèmes de performances. De plus, certains fournisseurs de framework d’API créent automatiquement cette couche et utilisent l’IA pour améliorer les performances, éliminer les redondances et supprimer les fonctionnalités inutilisées.
Grandes organisations
L’approche de connectivité basée sur l’API est avantageuse dans une grande organisation où vous aurez plusieurs équipes de développement. Vos différents secteurs d’activité peuvent chacun travailler sur des API au sein de leur propre domaine dans la couche de processus. Par exemple, vos partenaires Web, mobiles ou tiers peuvent se connecter aux API au niveau de la couche d’expérience. De même, la couche système peut être gérée par des groupes informatiques centraux associés à vos différents systèmes d’enregistrement.
Avantages et inconvénients
Certaines plaintes courantes que j’entends concernant cette approche à trois couches sont qu’il y a plusieurs sauts de réseau d’une couche à l’autre, et il y a une complexité supplémentaire à cette approche. Ce sont les mêmes questions que j’ai entendues lorsque nous sommes passés à model-view-controller ou lorsque nous avions des serveurs différents pour la base de données et l’application. Cependant, une application bien conçue l’emportera toujours sur quelques millisecondes de performances. Une approche de connectivité basée sur l’API peut améliorer les performances en ajoutant la mise en cache, le contrôle des pics et la surveillance de plusieurs consommateurs et en dimensionnant correctement la sécurité sur la couche système. Notez également que la sécurité est généralement maintenue au niveau des couches d’expérience et du système, tandis que la couche de processus est généralement sécurisée avec une sécurité plus rapide au niveau de l’identifiant client et du mot de passe. Cela peut conduire à une performance globale plus rapide de vos systèmes.
Deux autres avantages importants d’une approche basée sur l’API sont la réutilisabilité et la possibilité de connecter rapidement de nouveaux consommateurs et systèmes d’enregistrement.
Résumé
Il s’agit d’une vue d’ensemble de ce qu’est la connectivité pilotée par API et pourquoi vous devriez l’utiliser. Avons-nous besoin d’une couche d’expérience ? La couche d’expérience doit-elle être divisée par domaine, canal ou partenaire ? Comment devez-vous modéliser les données dans vos API système ? À l’avenir, j’entrerai plus en détail avec des cas d’utilisation, des exemples de chaque couche et comment cela peut aider votre organisation. Veuillez partager votre expérience avec la connectivité pilotée par API, y compris les avantages et les conséquences.