Le modèle de passerelle API (ou proxy) est très répandu dans l'architecture moderne. Dans ce modèle, le composant passerelle API joue le rôle de point d'entrée unique et d'intergiciel entre les applications clientes et les services dorsaux. Il offre diverses fonctionnalités de gestion des API, notamment le routage, la composition des requêtes, l'audit et la sécurité, entre autres.
Cet article décrit les avantages potentiels de la mise en œuvre de ce modèle dans des solutions basées sur un serveur FHIR.
Qu'est-ce que le modèle de passerelle API ?
L'architecture en 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 modèle de passerelle API répond à ce défi en fournissant un point de contrôle central pour toutes les API de l'ensemble des microservices.
Plusieurs solutions, tant commerciales qu'à code source ouvert, sont disponibles pour mettre en œuvre ce modèle. Parmi les exemples populaires, on trouve Apigee, Kong, Nginx et AWS API Gateway. Certaines solutions sont relativement simples et fonctionnent comme des proxies d'API, tandis que d'autres offrent des fonctionnalités plus complètes et sont désignées sous le nom de plateformes de gestion des API. Toutefois, 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é interne des services.
- Protégeant les API FHIR publiques contre les 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é interne des services
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, toute modification de l'architecture dorsale nécessiterait la mise à jour de chaque client, rendant la gestion fastidieuse. Comment exposer ces services dorsaux aux clients d'une manière qui dissimule la complexité et évite de partager trop d'informations internes ?
Solution
Mettre en œuvre une passerelle API qui constitue un point d'entrée unique pour tous les clients.
- La passerelle API fournit une interface stable et centrale pour les clients, permettant de modifier 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 maintenance de cette interface stable.
- Elle achemine la requête vers le service approprié 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 rationalise le contrôle d'accès en s'intégrant à 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 à des développeurs ou applications tiers via Internet. Comment atténuer le risque lié aux menaces Web courantes dans ce contexte ?
Solution
Mettre en œuvre une passerelle API pour gérer l'accès et assurer la 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 du débit et aux quotas, qui restreignent le nombre de requêtes qu'un client peut adresser à une API sur une période donnée.
- Elle peut contrôler l'accès aux API en autorisant ou en refusant les requêtes provenant d'adresses IP ou de plages d'adresses spécifiques, renforçant ainsi 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), composant spécialement conçu pour détecter et prévenir divers types de cyberattaques ciblant les applications Web.
Ajout de logique personnalisée en amont de FHIR
Problème
Nous devons mettre en œuvre une logique métier supplémentaire qui dépasse les capacités natives du serveur FHIR. Cela inclut la gestion de règles d'autorisation complexes reposant 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 obtenir un contrôle total sur toutes les requêtes traitées par le serveur FHIR afin de mettre en œuvre efficacement ces personnalisations ?
Solution
Mettre en œuvre un composant intergiciel personnalisé placé en amont du 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 et 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 des 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 en fonction des rôles des utilisateurs.
- Les requêtes peuvent être dirigées vers des services dorsaux spécifiques ou même placées dans un stockage en 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 vers 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 cherchons à minimiser la surcharge d'infrastructure.
Solution
Utiliser la fonctionnalité Aidbox Apps.
- Aidbox joue le rôle de proxy : il gère l'authentification et l'autorisation, et achemine la requête vers le code de l'application personnalisée.
- Plusieurs langages de programmation dans le SDK Aidbox prennent en charge Aidbox Apps.
Résumé
La mise en œuvre du modèle de passerelle API offre de puissantes fonctionnalités, et on peut même envisager de combiner plusieurs des modèles dont nous avons discuté. Cela pourrait aboutir à plusieurs couches de composants traitant chaque requête entrante, ajoutant davantage d'étapes au flux de requêtes.
Cependant, il est essentiel de prendre en compte les inconvénients potentiels de la mise en œuvre d'une 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 la garantie d'une haute disponibilité.
- Impact sur les performances : Une passerelle API introduit un saut réseau supplémentaire, ce qui peut 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, le diagnostic des problèmes peut s'avérer plus difficile, car les problèmes pourraient provenir de la passerelle ou des services sous-jacents.
- Limitations de personnalisation : Les solutions de passerelle API disponibles sur le marché peuvent ne pas offrir la personnalisation requise pour certains cas d'utilisation spécialisés.
Lorsque vous décidez de mettre en œuvre une passerelle API, évaluez soigneusement ses avantages et ses inconvénients pour votre situation particulière. La décision doit ê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 heureux 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 pour la santé.
