Das API-Gateway-Muster (oder Proxy-Muster) ist in der modernen Architektur weit verbreitet. Bei diesem Muster fungiert die API-Gateway-Komponente als zentraler Einstiegspunkt und Middleware zwischen Client-Anwendungen und Backend-Diensten. Es bietet verschiedene API-Management-Funktionen wie Routing, Request Composition, Audit und Sicherheit und vieles mehr.
Dieser Artikel beschreibt die potenziellen Vorteile der Implementierung dieses Musters mit FHIR-Server-basierten Lösungen.
Was ist das API-Gateway-Muster?
Die Microservice-Architektur zerlegt Anwendungen in kleinere, unabhängige Dienste, jeder mit seiner eigenen API. Sie verbessert Modularität und Flexibilität, erhöht jedoch die Komplexität im API-Management. Das API-Gateway-Muster begegnet dieser Herausforderung, indem es einen zentralen Kontrollpunkt für alle APIs über alle Microservices hinweg bereitstellt.
Für die Implementierung dieses Musters stehen sowohl kommerzielle als auch Open-Source-Lösungen zur Verfügung. Bekannte Beispiele sind Apigee, Kong, Nginx und AWS API Gateway. Einige Lösungen sind vergleichsweise einfach und fungieren als API-Proxys, während andere umfangreichere Funktionen bieten und als API-Management-Plattformen bezeichnet werden. Für die Zwecke dieses Artikels verwenden wir jedoch den Begriff „API Gateway", um alle derartigen Lösungen zu umfassen.
FHIR API Gateway: Anwendungsfälle
FHIR standardisiert den Datenaustausch im Gesundheitswesen, während API-Gateways FHIR-APIs durch folgende Aspekte verbessern:
- Zentralisierung der API, die die interne Dienstkomplexität abstrahiert.
- Schutz öffentlicher FHIR-APIs vor verbreiteten Web-Bedrohungen.
- Ermöglichung der Hinzufügung von benutzerdefinierter Logik, bevor Anfragen den FHIR-Server erreichen.
Diese Kombination schafft eine robuste und flexible Datenverwaltungsinfrastruktur im Gesundheitswesen.
Zentralisierte API, die die interne Dienstkomplexität abstrahiert
Problem
Wir verfügen über eine komplexe Backend-Lösung, die aus mehreren Diensten besteht, und müssen den Zugriff von Web- und mobilen Clients ermöglichen. Wenn jeder Client direkt mit jedem Dienst über spezifische Hostnamen und Ports interagiert, erfordert jede Änderung an der Backend-Architektur die Aktualisierung aller Clients, was die Verwaltung umständlich macht. Wie können wir diese Backend-Dienste für Clients verfügbar machen, ohne die Komplexität preiszugeben und zu viele interne Informationen weiterzugeben?
Lösung
Implementierung eines API-Gateways als zentralen Einstiegspunkt für alle Clients.
- Das API-Gateway bietet eine zentrale, stabile Schnittstelle für Clients und ermöglicht Änderungen an der Backend-Architektur, ohne dass Client-Konfigurationen aktualisiert werden müssen. Die Einhaltung des FHIR-Standards vereinfacht die Erstellung und Pflege dieser stabilen Schnittstelle.
- Es leitet die Anfrage an den richtigen Dienst weiter und trägt dazu bei, die Arbeitslast über mehrere Instanzen eines Dienstes zu verteilen, was Zuverlässigkeit und Skalierbarkeit verbessert.
- Das API-Gateway zentralisiert und optimiert die Zugriffskontrolle durch Integration mit einem Identity and Access Management (IAM)-Anbieter.
Schutz öffentlicher FHIR-APIs vor Web-Bedrohungen
Problem
Robuster und sicherer Zugriff auf die FHIR-API für Drittentwickler oder Anwendungen über das Internet soll bereitgestellt werden. Wie lässt sich in diesem Fall das Risiko verbreiteter Web-Bedrohungen mindern?
Lösung
Implementierung eines API-Gateways zur Verwaltung des Zugriffs und zum Schutz vor Web-Bedrohungen.
- Das API-Gateway kann Distributed-Denial-of-Service-Angriffe (DDoS) und anderen Missbrauch durch Rate Limiting und Kontingente abmildern, die die Anzahl der Anfragen einschränken, die ein Client in einem bestimmten Zeitraum an eine API stellen kann.
- Es kann den Zugriff auf APIs steuern, indem es Anfragen von bestimmten IP-Adressen oder -Bereichen zulässt oder ablehnt, und so die Sicherheit durch Beschränkung des Zugriffs auf vertrauenswürdige Netzwerke erhöht.
- Das API-Gateway kann auch in eine WAF (Web Application Firewall) integriert werden, eine Komponente, die speziell dafür entwickelt wurde, verschiedene Arten von Cyberangriffen auf Webanwendungen zu erkennen und zu verhindern.
Hinzufügen benutzerdefinierter Logik vor FHIR
Problem
Wir müssen zusätzliche Geschäftslogik implementieren, die über die nativen Funktionen des FHIR-Servers hinausgeht. Dazu gehören komplexe Autorisierungsregeln, die auf externen Daten basieren, die nicht im FHIR-Server gespeichert sind, oder die Anwendung benutzerdefinierter Routing-Regeln, beispielsweise das Replizieren von Anfragen an ein anderes Legacy-System während eines Migrationsprozesses.
Wie können wir die vollständige Kontrolle über alle vom FHIR-Server verarbeiteten Anfragen erlangen, um diese Anpassungen effektiv umzusetzen?
Lösung
Implementierung einer benutzerdefinierten Middleware-Komponente, die vor dem FHIR-Server sitzt und es ermöglicht, alle eingehenden Anfragen abzufangen und zu verarbeiten sowie eigene Geschäftslogik auszuführen, bevor diese den FHIR-Server erreichen.
- Das API-Gateway kann komplexe benutzerdefinierte Authentifizierungs- und Autorisierungs-Workflows verwalten, einschließlich der Introspektion opaker Token und der Nutzung externer Daten für Autorisierungsentscheidungen.
- Das API-Gateway kann Anfragen basierend auf bestimmten Regeln oder Bedingungen prüfen, weiterleiten oder blockieren, bevor sie den FHIR-Server erreichen. Es kann beispielsweise nur bestimmte Arten von Abfragen zulassen oder sensible Informationen basierend auf Benutzerrollen herausfiltern.
- Anfragen können je nach Art der Daten oder Anfrage an bestimmte Backend-Dienste weitergeleitet oder in einen Zwischenwarteschlangenspeicher eingestellt werden, sodass das API-Gateway als intelligenter Router fungiert und komplexe Szenarien bewältigt, z. B. die Migration von einem FHIR-Server zu einem anderen.
Verwendung von Aidbox als FHIR API Gateway
Problem
Wir müssen Aidbox um benutzerdefinierte Operationen erweitern und dabei eine Programmiersprache verwenden, die wir bereits kennen. Indem wir auf die Einführung zusätzlicher Komponenten in die Architektur verzichten, möchten wir den Infrastrukturaufwand minimieren.
Lösung
Verwendung der Aidbox Apps-Funktionalität.
- Aidbox fungiert als Proxy, übernimmt Authentifizierung und Autorisierung und leitet die Anfrage an den benutzerdefinierten App-Code weiter.
- Das Aidbox SDK unterstützt Aidbox Apps in mehreren Programmiersprachen.
Zusammenfassung
Die Implementierung des API-Gateway-Musters bietet leistungsstarke Möglichkeiten, und man kann sogar daran denken, mehrere der besprochenen Muster zu kombinieren. Dies kann zu mehreren Schichten von Komponenten führen, die jede eingehende Anfrage verarbeiten und dem Anfrage-Flow weitere Schritte hinzufügen.
Es ist jedoch wichtig, die potenziellen Nachteile der Implementierung eines API-Gateway-Musters zu berücksichtigen:
- Erhöhte Komplexität: Die Einführung eines API-Gateways fügt der Architektur eine zusätzliche Komponente hinzu, die zusätzliches Fachwissen für Konfiguration, Monitoring und die Sicherstellung der Hochverfügbarkeit erfordert.
- Auswirkungen auf die Performance: Ein API-Gateway führt zu einem zusätzlichen Netzwerk-Hop, was die Latenz potenziell erhöht. In leistungskritischen Systemen kann diese zusätzliche Schicht zum Engpass werden.
- Komplexeres Debugging: Mit einer zusätzlichen Schicht zwischen Clients und Diensten kann die Fehlerdiagnose schwieriger werden, da Probleme sowohl vom Gateway als auch von den zugrunde liegenden Diensten stammen können.
- Einschränkungen bei der Anpassung: Standardmäßige API-Gateway-Lösungen bieten möglicherweise nicht die für bestimmte Spezialanwendungsfälle erforderlichen Anpassungsmöglichkeiten.
Wenn Sie entscheiden, ob Sie ein API-Gateway implementieren möchten, sollten Sie dessen Vor- und Nachteile für Ihre spezifische Situation sorgfältig abwägen. Die Entscheidung sollte auf der Architektur Ihres Systems, den Anforderungen, der Teamstruktur und den langfristigen Zielen basieren.
Möchten Sie Ihren konkreten Anwendungsfall besprechen? Bitte zögern Sie nicht, uns zu kontaktieren. Wir helfen Ihnen gerne weiter.
Der Aidbox FHIR-Server kann lokal in nur 90 Sekunden bereitgestellt oder noch schneller über eine kostenlose Cloud-Sandbox genutzt werden – eine ideale Plattform zum Lernen und Entwickeln. Kostenlose Entwicklerlizenzen sind ebenfalls verfügbar.
Autor: Aleksandr Kislitsyn, Solution Architect bei Health Samurai
Siehe auch: Token-Introspektion in FHIR und Aufbau von Healthcare-Microservices.
