Avec la découverte de Mulesoft, nous entendons souvent parler de l'API-LED Connectivity. Quels sont ces mots simples et ambigus à la fois ? Au vu du nom, on comprend que cela concerne la technologie API. Le mot “LED” peut nous faire penser à de petites lumières qui s’unissent pour nous éclairer mieux et “Connectivity” peut nous renvoyer à une idée d'interconnexion ou de communication. Ainsi, on peut déduire que cet ensemble de mots désigne un ensemble d’APIs qui fonctionnent en communiquant entre elles pour effectuer un meilleur travail...

Essayons de mieux comprendre le sens de ces mots et surtout comment on peut mettre en pratique ce concept.

‍

Qu’est-ce que l’API-LED Connectivity ?

En faisant une brève recherche sur Google, nous pouvons trouver diverses définitions et explications du concept API-LED Connectivity. En voici un exemple :

“API-LED Connectivity est un moyen méthodique de connecter les données aux applications via des API réutilisables et utiles au sein de l'écosystème d'une organisation. Ces API sont développées pour jouer un rôle spécifique : libérer les données des systèmes, composer des données en processus ou offrir une expérience." (https://www.salesforce.com/blog/api-led-connectivity/)

‍

À partir de cette définition, nous pouvons comprendre que le concept API-LED Connectivity est plutôt un modèle d’architecture au niveau de l'infrastructure des APIs, nous conseillant de créer des APIs simples et réutilisables ayant un certain but fonctionnel :

• Libérer les données des systèmes : des APIs qui font partie d’une couche système
• Composer des données en processus : des APIs qui font partie d’une couche processus
• Offrir une expérience : des APIs qui font partie d’une couche expérience

Ainsi, il y a trois types d’APIs organisées en couches, qui sont réutilisables et communiquent entre elles. Chaque couche d’APIs a un but précis et permet de faciliter la réutilisation et la maintenance de votre infrastructure des APIs.

‍
Nous pouvons le visualiser sous la forme d’un schéma qu’on découvre souvent en même temps que Mulesoft (https://www.salesforce.com/blog/api-led-connectivity/) :

Sur le schéma ci-dessus, nous pouvons bien observer les 3 couches qui regroupent différents APIs. Comme le dit la définition, les APIs de la couche systèmes communiquent avec les systèmes externes, les APIs de la couche processus récupèrent les données de différentes sources pour les traiter, transformer, composer… et les APIs de la couche expérience représentent un point d’entrée pour les services externes afin de consommer les données en adaptant leurs services au système source d’appel pour une meilleure expérience de consommation de service exposé par l’API.

Mais avant de passer à la suite, concentrons-nous sur le rôle de chaque couche d’APIs.

‍

Couche Système

Les APIs de cette couche ont pour but de “libérer les données des systèmes”. C’est-à-dire, que le rôle d’une API système est simplement d'ouvrir l’accès à un système externe. Aucune transformation ni logique de traitement n’a sa place dans cette API. Cette API est une porte d’accès vers un système externe. On peut dire qu’elle représente une interface d’accès vers ce système et doit pouvoir exposer les données de la manière la plus brute possible ou pousser les données dans le système sous le format exigé par le système.

‍

Couche Processus

Les APIs de cette couche ont pour but de “composer des données en processus”. Effectivement, le rôle d’une API processus est de récupérer les données de diverses sources et de les transformer, les filtrer, les modifier, les renommer ou tout ce que le besoin fonctionnel (ou votre imagination) demande de faire. C’est à ce niveau que nous pouvons mettre en place une logique d’orchestration et de contrôle d’un processus. Très souvent, les APIs processus vont récupérer les données des autres APIs processus et/ou des APIs systèmes pour appliquer une transformation ou action répondant à un besoin métier.

‍

Couche Expérience

La fameuse couche expérience qui regroupe des APIs ayant pour but “d'offrir une expérience”. Ces APIs représentent une porte d'entrée des systèmes externes dans toute l’infrastructure d’API-LED Connectivity. Comparées aux APIs des autres couches, l’expérience est toujours publique (ou ouverte d’accès depuis un réseau fermé à un ensemble de systèmes externes). Son rôle est de sécuriser l’accès à l'infrastructure et de fournir une expérience de consommation d’API propre à chaque système consommateur.

Par exemple, si un système externe a besoin des données au format JSON avec un header particulier et une validation par token et qu’un autre système a besoin des mêmes données au format CSV, sans header, avec une authentification de base et une liste blanche d’IP, dans ce cas, nous allons créer 2 APIs expérience pour répondre à ce besoin.

Maintenant que nous avons vu plus en détail les rôles et le fonctionnement des différentes couches d’API-LED, il faut également retenir que des exceptions aux règles décrites ci-dessus ne sont pas à exclure.

‍

L'API LED n'est pas gravée dans le marbre !

Nous avons vu un peu plus en détail ce qu’était API-LED Connectivity, mais qu’en est-il en pratique ?

C’est vrai qu'en théorie, l’architecture API-LED a plein de sens et d’avantages. Mais ça ne veut pas dire que c’est une règle absolue et qu’on doit essayer de caser tous nos besoins dans le moule de API-LED Connectivity. Le plus important est d’adapter le paterne à votre besoin afin d’obtenir le résultat optimal.

l’API-LED Connectivity est là pour vous aider à rendre votre infrastructure plus facile à évoluer, plus rapide à développer (notamment grâce à la réutilisation) et plus simple à maintenir.

Dans différents cas, nous n’avons pas forcément besoin de couche expérience, si notre infrastructure utilise souvent des événements ou un système de “queuing”.

Dans le cas ou 2 systèmes externes sont alignés sur les modèles de données traités, ils peuvent ne pas avoir besoin de la couche processus et juste effectuer des transitions “passe-plat”.

Il est également intéressant de se poser la question sur le découpage de mes APIs. Il est facile de se dire que c’est plus simple de faire par exemple une API processus qui comporte un ensemble de web services nécessaires pour toutes les transformations fonctionnelles exprimées par un ou des besoins métiers. Ou bien, d'un autre côté, avoir tendance à découper de manière excessive et viser une granularité trop fine et difficile à maintenir. 

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

Conclusion

Le plus important à comprendre est que l’API-LED Connectivity a pour but de mettre en place une infrastructure évolutive et facilement modulable. À vous de trouver le juste milieu pour au mieux répondre à vos besoins à court et long terme.