El patrón API Gateway (o Proxy) es muy popular en la arquitectura moderna. En este patrón, el componente API Gateway actúa como punto de entrada único y como middleware entre las aplicaciones cliente y los servicios backend. Proporciona diversas capacidades de gestión de APIs, tales como enrutamiento, composición de solicitudes, auditoría y seguridad, entre otras.
Este artículo describe los posibles beneficios de implementar este patrón en soluciones basadas en servidores FHIR.
Nota sobre el alcance: un API Gateway se sitúa delante de un servidor FHIR y gestiona el tráfico de clientes (enrutamiento, autenticación, limitación de velocidad). Si su problema es de tipo ascendente —ingesta de HL7 v2, X12 o C-CDA desde sistemas EHR heredados y su mapeo a FHIR—, eso corresponde a un motor de integración sanitaria, no a un API Gateway. Para ese patrón, consulte Interbox, nuestro motor de integración FHIR.
¿Qué es el Patrón API Gateway?
La Arquitectura de Microservicios descompone las aplicaciones en servicios más pequeños e independientes, cada uno con su propia API. Esto mejora la modularidad y la flexibilidad a costa de una mayor complejidad en la gestión de APIs. El patrón API Gateway aborda este desafío al proporcionar un punto central de control para todas las APIs de todos los microservicios.
Existen diversas soluciones, tanto comerciales como de código abierto, para implementar este patrón. Entre los ejemplos más populares se encuentran Apigee, Kong, Nginx y AWS API Gateway. Algunas soluciones son relativamente sencillas y funcionan como proxies de API, mientras que otras ofrecen características más completas y se denominan Plataformas de Gestión de APIs. No obstante, a efectos de este artículo, utilizaremos el término «API Gateway» para englobar todas estas soluciones.
FHIR API Gateway: Casos de Uso
FHIR estandariza el intercambio de datos sanitarios, mientras que los API Gateways mejoran las APIs FHIR mediante:
- La centralización de la API que abstrae la complejidad interna de los servicios.
- La protección de las APIs FHIR públicas frente a amenazas web habituales.
- La posibilidad de añadir lógica personalizada antes de que las solicitudes lleguen al servidor FHIR.
Esta combinación crea una infraestructura de datos sanitarios robusta y flexible.
API centralizada que abstrae la complejidad interna de los servicios
Problema
Disponemos de una solución backend compleja compuesta por múltiples servicios y necesitamos permitir el acceso desde clientes web y móviles. Si cada cliente interactúa directamente con cada servicio utilizando nombres de host y puertos específicos, cualquier cambio en la arquitectura backend requeriría actualizar cada cliente, lo que dificulta enormemente su gestión. ¿Cómo podemos exponer estos servicios backend a los clientes de forma que se oculte la complejidad y se evite compartir demasiada información interna?
Solución
Implementar un API Gateway que sea el punto de entrada único para todos los clientes.
- El API Gateway proporciona una interfaz central y estable para los clientes, lo que permite realizar cambios en la arquitectura backend sin necesidad de actualizar las configuraciones de los clientes. La adhesión al estándar FHIR simplifica el proceso de creación y mantenimiento de esta interfaz estable.
- Enruta la solicitud al servicio correcto y ayuda a equilibrar la carga de trabajo entre múltiples instancias de un servicio, mejorando la fiabilidad y la escalabilidad.
- El API Gateway centraliza y simplifica el Control de Acceso mediante su integración con un proveedor de Gestión de Identidades y Accesos (IAM).
Protección de la API FHIR pública frente a amenazas web
Problema
Proporcionar un acceso robusto y seguro a la API FHIR a desarrolladores o aplicaciones de terceros a través de Internet. ¿Cómo podemos mitigar el riesgo de las amenazas web habituales en este caso?
Solución
Implementar un API Gateway para gestionar el acceso y ofrecer protección frente a amenazas web.
- El API Gateway puede mitigar los ataques de denegación de servicio distribuido (DDoS) y otros abusos mediante la limitación de velocidad y cuotas, que restringen el número de solicitudes que un cliente puede realizar a una API en un período determinado.
- Puede controlar el acceso a las APIs permitiendo o denegando solicitudes procedentes de direcciones IP o rangos específicos, mejorando la seguridad al restringir el acceso a redes de confianza.
- El API Gateway también puede integrarse con un WAF (Web Application Firewall), el componente diseñado específicamente para detectar y prevenir diversos tipos de ciberataques dirigidos a aplicaciones web.
Adición de Lógica Personalizada delante de FHIR
Problema
Necesitamos implementar lógica de negocio adicional que va más allá de las capacidades nativas del servidor FHIR. Esto incluye la gestión de reglas de autorización complejas que dependen de datos externos no almacenados en el servidor FHIR, o la aplicación de reglas de enrutamiento personalizadas, como la replicación de solicitudes a otro sistema heredado durante un proceso de migración.
¿Cómo podemos obtener control total sobre todas las solicitudes procesadas por el servidor FHIR para implementar estas personalizaciones de manera efectiva?
Solución
Implementar un componente middleware personalizado que se sitúe delante del servidor FHIR, permitiendo interceptar y procesar todas las solicitudes entrantes y ejecutar la lógica de negocio propia antes de que lleguen al servidor FHIR.
- El API Gateway puede gestionar flujos de trabajo complejos de autenticación y autorización personalizados, incluyendo la introspección de tokens opacos y el uso de datos externos para tomar decisiones de autorización.
- El API Gateway puede inspeccionar, enrutar o bloquear solicitudes basándose en reglas o condiciones específicas antes de que lleguen al servidor FHIR. Por ejemplo, puede permitir únicamente ciertos tipos de consultas o filtrar información sensible según los roles de los usuarios.
- Las solicitudes pueden dirigirse a servicios backend específicos o incluso enviarse a un almacenamiento de cola intermedio en función del tipo de datos o solicitud, lo que permite al API Gateway actuar como un enrutador inteligente y gestionar escenarios complejos, como la migración de un servidor FHIR a otro.
Uso de Aidbox como FHIR API Gateway
Problema
Necesitamos añadir operaciones personalizadas a Aidbox utilizando un lenguaje de programación que ya conocemos. Al evitar la introducción de componentes adicionales en la arquitectura, buscamos minimizar la sobrecarga de infraestructura.
Solución
Utilizar la funcionalidad Aidbox Apps.
- Aidbox actúa como proxy: gestiona la autenticación y la autorización, y enruta la solicitud al código de la App personalizada.
- El SDK de Aidbox admite Aidbox Apps en múltiples lenguajes de programación.
Resumen
La implementación del patrón API Gateway ofrece potentes capacidades, e incluso puede considerarse la combinación de múltiples patrones de los que hemos analizado. Esto podría dar lugar a múltiples capas de componentes que procesen cada solicitud entrante, añadiendo más pasos al flujo de solicitudes.
No obstante, es fundamental tener en cuenta los posibles inconvenientes de implementar un patrón API Gateway:
- Mayor complejidad: La introducción de un API Gateway añade un componente adicional a la arquitectura, lo que requiere experiencia adicional para su configuración, monitorización y garantía de alta disponibilidad.
- Impacto en el rendimiento: Un API Gateway introduce un salto de red adicional, lo que puede aumentar la latencia. En sistemas sensibles al rendimiento, esta capa adicional podría convertirse en un cuello de botella.
- Depuración más compleja: Con una capa adicional entre los clientes y los servicios, el diagnóstico de problemas puede resultar más difícil, ya que estos podrían originarse en el gateway o en los servicios subyacentes.
- Limitaciones de personalización: Las soluciones de API Gateway disponibles en el mercado pueden no ofrecer la personalización necesaria para determinados casos de uso especializados.
A la hora de decidir si implementar un API Gateway, evalúe detenidamente sus ventajas e inconvenientes para su situación específica. La decisión debe basarse en la arquitectura de su sistema, los requisitos, la estructura del equipo y los objetivos a largo plazo.
¿Le gustaría comentar su caso de uso particular? No dude en contactar con nosotros. Estaremos encantados de ayudarle.
El servidor FHIR Aidbox puede desplegarse localmente en tan solo 90 segundos o accederse de forma aún más rápida a través de un Sandbox gratuito en la nube, lo que lo convierte en una plataforma ideal para el aprendizaje y el desarrollo. También hay disponibles licencias de desarrollo gratuitas.
Autor: Aleksandr Kislitsyn, Arquitecto de Soluciones en Health Samurai
Véase también: Introspección de tokens en FHIR y Construcción de microservicios sanitarios.
