Le modèle de passerelle API (ou mandataire) est populaire dans l'architecture moderne. Dans ce modèle, la passerelle API joue le rôle de point d'entrée unique et d'intergiciel entre les applications clientes et les services dorsaux. Elle offre diverses fonctionnalités de gestion des API, notamment le routage, la composition des requêtes, l'audit et la sécurité, et bien plus encore.
Cet article décrit les avantages potentiels de la mise en œuvre de ce modèle avec des solutions fondées sur un serveur FHIR.
Qu'est-ce que le modèle de 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 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, à la fois commerciales et à code source ouvert, sont disponibles pour mettre en œuvre ce modèle. Parmi les exemples populaires, on compte Apigee, Kong, Nginx et AWS API Gateway. Certaines solutions sont relativement simples et fonctionnent comme des mandataires d'API, tandis que d'autres offrent des fonctionnalités plus complètes et sont appelées 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 fait abstraction de la complexité interne des services.
- Protégeant les API FHIR publiques contre les menaces Web courantes.
- Permettant l'ajout d'une 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.
API centralisée faisant abstraction de 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 peut-on exposer ces services dorsaux aux clients d'une façon qui dissimule la complexité et évite de partager trop d'informations internes?
Solution
Mettre en place une passerelle API qui constitue un point d'entrée unique pour tous les clients.
- La passerelle API fournit une interface centrale et 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 service approprié et aide à é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 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 sur Internet. Comment peut-on atténuer le risque des menaces Web courantes dans ce cas?
Solution
Mettre en place 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 de débit et aux quotas, qui restreignent le nombre de requêtes qu'un client peut adresser à une API au cours d'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 avec un pare-feu d'applications Web (WAF), le composant spécialement conçu pour détecter et prévenir divers types de cyberattaques ciblant les applications Web.
Ajout d'une logique personnalisée devant 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 comprend la gestion de règles d'autorisation complexes qui s'appuient 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 pendant un processus de migration.
Comment peut-on obtenir un contrôle total sur toutes les requêtes traitées par le serveur FHIR pour mettre en œuvre ces personnalisations efficacement?
Solution
Mettre en place un composant intergiciel personnalisé placé devant le serveur FHIR, vous permettant d'intercepter et de traiter toutes les requêtes entrantes, ce qui permet l'exécution de 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, y compris 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 selon les rôles des utilisateurs.
- Les requêtes peuvent être dirigées vers des services dorsaux spécifiques ou même être 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 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 agit comme un mandataire, il gère l'authentification et l'autorisation et achemine la requête vers le code de l'App 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 vous pouvez même envisager de combiner plusieurs modèles dont nous avons discuté. Cela pourrait se traduire par plusieurs couches de composants traitant chaque requête entrante, ajoutant plus d'étapes au flux de requêtes.
Cependant, il est essentiel de tenir compte des inconvénients potentiels de la mise en œuvre d'un modèle de 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 supplémentaire 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 devenir 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 nécessaire pour certains cas d'utilisation spécialisés.
Au moment de décider si vous devez mettre en place 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 de santé.
