Imaginons le problème : votre entreprise crée un produit B2B qui fournit un service à d’autres entreprises. Ce service aide l’entreprise cliente à résoudre les problèmes très spécifiques de ses clients. Ce client peut communiquer avec l’application Web de notre entreprise et effectuer certaines opérations. Les résultats de ces opérations doivent être communiqués à l’autre partie de l’entreprise.
Les temps passent et vous avez maintenant quelques clients de plus qui travaillent selon le même schéma. Au début, vous connectez les petites entreprises une par une, mais lorsque vous arrivez à des entreprises clientes beaucoup plus grandes, vous découvrez qu’elles utilisent des fournisseurs de services d’API tiers et leur délèguent tous les problèmes d’intégration. Ces fournisseurs de services d’API agissent comme un proxy pour ce travail d’intégration inversée de service, qui unifie la logique de communication inter-entreprises des deux côtés. En raison de la structure des relations commerciales présentées, notre entreprise commencera presque inévitablement à utiliser un ensemble d’actions similaires pour communiquer avec des dizaines d’API différentes pour des centaines de clients à l’avenir.
Pour faciliter les choses, nous devrions unifier la logique de communication entre nos services et les API externes.
L’idée principale est de créer un service de transaction évolutif unique et de l’utiliser pour transformer une sorte de DTO unifiés en informations spécifiques à l’API et vice versa.
Pour HTTP, nos adaptateurs doivent pouvoir :
- Transformez le DTO de requête unifié en DTO de requête spécifique à l’API
- Transformez le DTO de réponse spécifique à l’API et le code d’état HTTP en DTO de réponse unifié
Pour ce faire, dans un premier temps, nous devons comprendre les éléments constitutifs de notre communication.
La requête HTTP consiste en :
- méthode HTTP ;
- chemin URL ;
- Paramètres d’URL ;
- structure des en-têtes ;
- corps de la requête (tout format : JSON, XML, texte brut).
La réponse HTTP consiste en :
- En-têtes de réponse ;
- Corps de la réponse (peut également contenir un code d’erreur qui doit être combiné avec le code d’état HTTP et traduit dans un format de code d’erreur unifié).
Tous les éléments énumérés ci-dessus sont illustrés sur l’image suivante :
Il est important de comprendre quels éléments de communication peuvent varier entre les fournisseurs d’API et lesquels sont spécifiques au client. Par exemple, dans l’URL de l’API : le protocole, le nom de domaine et le port sont Spécifique au client parties, mais le chemin de l’URL de la demande et les paramètres de l’URL sont Spécifique à l’API.
Une fois que nous savons quels éléments doivent être unifiés dans nos adaptateurs, nous devons nous assurer que nous utilisons toujours le bon adaptateur pour notre demande. La façon la plus simple de le faire est d’utiliser un ClientId unique pour identifier un mot-clé unique d’API à partir de la base de données. Après en avoir obtenu un, nous pouvons simplement utiliser static Map
Il est fortement recommandé que les données de demande unifiées aient des informations complètes sur les entités. De cette façon, vous ne rencontrerez jamais de manque d’informations du côté de l’adaptateur API. Par exemple, si une demande dans votre service de transaction contient le champ « ClientId », envisagez d’obtenir l’intégralité de ClientEntity [clientId, apiKey, mainCurrency, URL_protocol, domain, … ] de la base de données et transmettez-le dans votre adaptateur (faites-le comme vous le souhaitez).
Après avoir combiné ces 2 étapes simples, nous avons obtenu la structure de code suivante :
Désormais, chaque fois que vous devez effectuer une intégration inverse d’API, il vous suffit d’ajouter de nouveaux adaptateurs de requête et de réponse et d’effectuer toutes les transformations spécifiques à l’API nécessaires en un seul endroit.