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 intermediario entre las aplicaciones cliente y los servicios backend. Ofrece diversas capacidades de gestión de APIs, 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.
¿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 proporcionando 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 mediante nombres de host y puertos específicos, cualquier cambio en la arquitectura backend obligaría a actualizar todos los clientes, 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 único punto de entrada 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 las solicitudes 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 agiliza el Control de Acceso mediante la 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 para 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, reforzando 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.
Incorporación de lógica personalizada frente a 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 forma eficaz?
Solución
Implementar un componente middleware personalizado que se sitúe frente al servidor FHIR, permitiéndole interceptar y procesar todas las solicitudes entrantes y ejecutar su propia lógica de negocio antes de que lleguen al servidor FHIR.
- El API Gateway puede gestionar flujos de trabajo complejos de autenticación y autorización personalizados, incluida 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 en función de 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 en función de los roles de usuario.
- Las solicitudes pueden dirigirse a servicios backend específicos o incluso enviarse a un almacenamiento en cola intermedio en función del tipo de datos o solicitud, lo que permite al API Gateway actuar como 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, pretendemos 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 capacidades muy potentes, e incluso se puede considerar la combinación de varios de los patrones 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, supervisió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 concreta. La decisión debe basarse en la arquitectura de su sistema, los requisitos, la estructura del equipo y los objetivos a largo plazo.
¿Desea comentar su caso de uso particular? No dude en ponerse en contacto con nosotros. Estaremos encantados de ayudarle.
El servidor FHIR Aidbox puede desplegarse localmente en tan solo 90 segundos o puede accederse a él aún más rápido a través de un Sandbox gratuito en la nube, lo que lo convierte en una plataforma ideal para aprendizaje y desarrollo. También están 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 en sanidad.
