Una puerta de enlace API es responsable de administrar la interfaz pública presentada a clientes externos. Debería manejar problemas de bajo nivel como:
- cumplimiento del protocolo
- listas negras
- limitación de velocidad
- cuotas
- versionado
- solicitar la normalización
Puede interactuar con:
- un sistema de descubrimiento para saber qué servicios web internos deben manejar qué puntos finales públicos
- un sistema de enrutamiento para saber cómo traducir rutas públicas a rutas internas
- un sistema de autorización para saber cómo traducir tokens de API externos a credenciales de autorización interna, para que los servicios web individuales no tengan que solicitarlos repetidamente.
En resumen, debería manejar problemas comunes en el área de superficie pública de la API. No debe tener ningún conocimiento de los detalles específicos de la lógica de negocios de un servicio web en particular o una ruta en particular.
Los servicios web individuales necesitan validar sus propias entradas. Solo los servicios individuales saben qué parámetros son válidos y qué tipos pueden asumir esos parámetros. Sin embargo, si los servicios web utilizan cargas útiles JSON, la puerta de enlace de la API puede realizar una validación JSON básica y quizás incluso comparar las cargas útiles con los esquemas JSON por cada URL.
Una puerta de enlace API puede manejar la autenticación, ya que generalmente se puede conectar a un proveedor de identidad, tiene conocimiento de varios protocolos de autenticación y se puede configurar para aprovisionar tokens de autorización. Aunque a menudo la gente tiene sus propios esquemas de autenticación y flujos de trabajo que van más allá de lo que proporciona una puerta de enlace API fuera de la caja.
Una API Gateway debe validar los tokens de autorización proporcionados por llamantes externos, y debe ayudar a simplificar algunos aspectos del control de acceso que enfrentan los servicios web individuales al mejorar las cargas útiles con roles o derechos a los que tiene derecho el token de autorización. Pero los servicios individuales siguen siendo responsables de las comprobaciones granulares de esos roles y la seguridad de la lógica empresarial.
Una puerta de enlace API a menudo se configura en el borde o en una DMZ, ya que se enfrenta a tráfico no confiable y tiene la responsabilidad de transformarlo en una forma más sintácticamente normalizada. Los servicios web siguen siendo responsables de la semántica.
Si una aplicación web que genera HTML consume API, hay una decisión de política sobre si esa aplicación consume solo API públicas, o también puede consumir API internas directamente desde los servicios web internos. Hay pros y contras para ambos lados. La arquitectura surge de esa decisión.