Le patron Passerelle API (ou Proxy) est populaire dans l'architecture moderne. Dans ce patron, le composant Passerelle API agit comme point d'entrée unique et intergiciel entre les applications clientes et les services dorsaux. Il offre diverses capacités de gestion des API telles que le routage, la composition de requêtes, l'audit et la sécurité, et bien plus encore.
Cet article décrit les avantages potentiels de l'implémentation de ce patron avec des solutions basées sur un serveur FHIR.
Note sur la portée : une passerelle API se place devant un serveur FHIR et gouverne le trafic client (routage, authentification, limitation de débit). Si votre problème se situe en amont — ingestion de HL7 v2, X12 ou C-CDA depuis des DSE patrimoniaux et leur transformation en FHIR — c'est le rôle d'un moteur d'intégration en santé, et non d'une passerelle API. Pour ce patron, consultez Interbox, notre moteur d'intégration FHIR.
Qu'est-ce que le patron Passerelle API ?
L'architecture de microservices décompose les applications en services plus petits et indépendants, chacun disposant de sa propre API. Cela améliore la modularité et la flexibilité au prix d'une complexité accrue dans la gestion des API. Le patron Passerelle API répond à ce défi en fournissant un point de contrôle central pour toutes les API à travers l'ensemble des microservices.
Plusieurs solutions, commerciales et à code source ouvert, sont disponibles pour implémenter ce patron. Les exemples populaires incluent Apigee, Kong, Nginx et AWS API Gateway. Certaines solutions sont relativement simples et fonctionnent comme des proxys API, tandis que d'autres offrent des fonctionnalités plus complètes et sont désignées comme plateformes de gestion des API. Cependant, aux fins de cet article, nous utiliserons le terme « passerelle API » pour englober toutes ces solutions.
Passerelle API FHIR : cas d'utilisation
FHIR standardise l'échange de données de santé, tandis que les passerelles API améliorent les API FHIR en :
- Centralisant l'API qui abstrait la complexité des services internes.
- Protégeant les API FHIR publiques des menaces Web courantes.
- Permettant l'ajout de logique personnalisée avant que les requêtes n'atteignent le serveur FHIR.
Cette combinaison crée une infrastructure de données de santé robuste et flexible.
Centralisation de l'API qui abstrait la complexité des services internes
Problème
Nous disposons d'une solution dorsale complexe composée de plusieurs services, et nous devons permettre l'accès depuis des clients Web et mobiles. Si chaque client interagit directement avec chaque service en utilisant des noms d'hôte et des ports spécifiques, tout changement dans l'architecture dorsale nécessiterait la mise à jour de chaque client, rendant la gestion fastidieuse. Comment pouvons-nous exposer ces services dorsaux aux clients d'une manière qui dissimule la complexité et évite de devoir partager trop d'informations internes ?
Solution
Implémenter une passerelle API qui constitue un point d'entrée unique pour tous les clients.
- La passerelle API fournit une interface centrale stable pour les clients, permettant des modifications de l'architecture dorsale sans avoir à mettre à jour les configurations des clients. Le respect de la norme FHIR simplifie le processus de création et de maintien de cette interface stable.
- Elle achemine la requête vers le bon service et contribue à équilibrer la charge de travail entre plusieurs instances d'un service, améliorant ainsi la fiabilité et l'évolutivité.
- La passerelle API centralise et simplifie le contrôle d'accès en s'intégrant avec un fournisseur de gestion des identités et des accès (IAM).
Protection de l'API FHIR publique contre les menaces Web
Problème
Fournir un accès robuste et sécurisé à l'API FHIR aux développeurs ou applications tiers via Internet. Comment pouvons-nous atténuer le risque des menaces Web courantes dans ce cas ?
Solution
Implémenter une passerelle API pour gérer les accès et offrir une protection contre les menaces Web.
- La passerelle API peut atténuer les attaques par déni de service distribué (DDoS) et d'autres abus grâce à la limitation de débit et aux quotas, qui restreignent le nombre de requêtes qu'un client peut effectuer vers une API dans une période donnée.
- Elle peut contrôler l'accès aux API en autorisant ou refusant les requêtes provenant d'adresses IP ou de plages d'adresses spécifiques, renforçant la sécurité en limitant l'accès aux réseaux de confiance.
- La passerelle API peut également être intégrée à un WAF (pare-feu d'application Web), le composant spécifiquement conçu pour détecter et prévenir divers types de cyberattaques ciblant les applications Web.
Ajout de logique personnalisée devant FHIR
Problème
Nous devons implémenter une logique métier supplémentaire qui dépasse les capacités natives du serveur FHIR. Cela comprend la gestion de règles d'autorisation complexes qui reposent sur des données externes non stockées dans le serveur FHIR, ou l'application de règles de routage personnalisées, comme la réplication des requêtes vers un autre système patrimonial lors d'un processus de migration.
Comment pouvons-nous obtenir un contrôle total sur toutes les requêtes traitées par le serveur FHIR afin d'implémenter ces personnalisations efficacement ?
Solution
Implémenter un composant intergiciel personnalisé qui se place devant le serveur FHIR, vous permettant d'intercepter et de traiter toutes les requêtes entrantes, et d'exécuter votre propre logique métier avant qu'elles n'atteignent le serveur FHIR.
- La passerelle API peut gérer des flux d'authentification et d'autorisation personnalisés complexes, notamment l'introspection de jetons opaques et l'utilisation de données externes pour prendre des décisions d'autorisation.
- La passerelle API peut inspecter, acheminer ou bloquer les requêtes selon des règles ou conditions spécifiques avant qu'elles n'atteignent le serveur FHIR. Par exemple, elle peut n'autoriser que certains types de requêtes ou filtrer les informations sensibles selon les rôles des utilisateurs.
- Les requêtes peuvent être dirigées vers des services dorsaux spécifiques ou même placées dans une file d'attente intermédiaire selon le type de données ou de requête, permettant à la passerelle API d'agir comme un routeur intelligent et de gérer des scénarios complexes, comme la migration d'un serveur FHIR à un autre.
Utilisation d'Aidbox comme passerelle API FHIR
Problème
Nous devons ajouter des opérations personnalisées à Aidbox en utilisant un langage de programmation que nous connaissons déjà. En évitant d'introduire des composants supplémentaires dans l'architecture, nous visons à minimiser la surcharge d'infrastructure.
Solution
Utiliser la fonctionnalité Aidbox Apps.
- Aidbox agit comme un proxy : il gère l'authentification et l'autorisation, puis achemine la requête vers le code de l'application personnalisée.
- Plusieurs langages de programmation dans le SDK Aidbox prennent en charge les Aidbox Apps.
Résumé
L'implémentation du patron Passerelle API offre de puissantes capacités et vous pouvez même envisager de combiner plusieurs des patrons que nous avons abordés. Cela pourrait se traduire par plusieurs couches de composants traitant chaque requête entrante, ajoutant davantage d'étapes au flux de traitement.
Cependant, il est essentiel de considérer les inconvénients potentiels de l'implémentation d'un patron Passerelle API :
- Complexité accrue : L'introduction d'une passerelle API ajoute un composant supplémentaire à l'architecture, nécessitant une expertise additionnelle pour la configuration, la surveillance et le maintien d'une haute disponibilité.
- Impact sur les performances : Une passerelle API introduit un saut réseau supplémentaire, pouvant augmenter la latence. Dans les systèmes sensibles aux performances, cette couche additionnelle pourrait devenir un goulot d'étranglement.
- Débogage plus complexe : Avec une couche supplémentaire entre les clients et les services, diagnostiquer les problèmes peut devenir plus difficile, car ceux-ci pourraient provenir de la passerelle ou des services sous-jacents.
- Limites de personnalisation : Les solutions de passerelle API disponibles sur le marché peuvent ne pas offrir la personnalisation nécessaire pour certains cas d'utilisation spécialisés.
Au moment de décider d'implémenter ou non une passerelle API, évaluez soigneusement ses avantages et inconvénients pour votre situation spécifique. La décision devrait être fondée sur l'architecture de votre système, vos exigences, la structure de votre équipe et vos objectifs à long terme.
Souhaitez-vous discuter de votre cas d'utilisation particulier ? N'hésitez pas à nous contacter. Nous serons ravis de vous aider.
Le serveur FHIR Aidbox peut être déployé localement en seulement 90 secondes ou accessible encore plus rapidement via un bac à sable infonuagique gratuit, ce qui en fait une plateforme idéale pour l'apprentissage et le développement. Des licences de développement gratuites sont également disponibles.
Auteur : Aleksandr Kislitsyn, Architecte de solutions chez Health Samurai
Voir aussi : Introspection de jetons dans FHIR et Création de microservices en santé.
