Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Patrones de enrutamiento de API En los entornos de desarrollo ágiles, los equipos autónomos (por ejemplo, escuadrones y tribus) poseen uno o más servicios que incluyen muchos microservicios. Los equipos exponen estos servicios como API para permitir a sus consumidores interactuar con su grupo de servicios y acciones. Existen tres métodos principales para exponer las API HTTP a los principales consumidores mediante el uso de nombres de host y rutas: | | | **Método** | **Descripción** | **Ejemplo** | | --- |--- |--- | | [**Enrutamiento por nombres de host**](api-routing-hostname.md) | Se expone cada servicio como un nombre de host. | `billing.api.example.com` | | [**Enrutamiento por rutas**](api-routing-path.md) | Se expone cada servicio como una ruta. | `api.example.com/billing` | | [**Enrutamiento basado en encabezados**](api-routing-http.md) | Se expone cada servicio como un encabezado HTTP. | `x-example-action: something` | En esta sección se describen los casos de uso típicos de estos tres métodos de enrutamiento y sus ventajas y desventajas para ayudarle a decidir qué método se adapta mejor a sus requisitos y estructura organizativa. # Patrón de enrutamiento por nombres de host El enrutamiento por nombre de host es un mecanismo para aislar los servicios de API al asignar a cada API su propio nombre de host; por ejemplo, `service-a.api.example.com` o `service-a.example.com`. ## Caso de uso típico El enrutamiento mediante nombres de host reduce la fricción en los lanzamientos, ya que los equipos de servicio no comparten nada. Los equipos son responsables de administrar todo, desde las entradas de DNS hasta las operaciones de servicio en producción. ![\[Patrón de enrutamiento de nombres de host para exponer las API HTTP a los consumidores ascendentes.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/cloud-design-patterns/images/routing-1.png) ## Ventajas El enrutamiento por nombres de host es, con diferencia, el método más sencillo y escalable para el enrutamiento de API HTTP. Puede utilizar cualquier servicio de AWS relevante para crear una arquitectura que siga este método: puede crear una arquitectura con [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/), [equilibradores de carga de aplicación](https://aws.amazon.com/elasticloadbalancing/) y [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/), o cualquier otro servicio compatible con HTTP. Los equipos pueden usar el enrutamiento por nombres de host para ser plenamente propietarios de su subdominio. También facilita el aislamiento, las pruebas y la orquestación de las implementaciones para Regiones de AWS o versiones específicas; por ejemplo, `region.service-a.api.example.com` o `dev.region.service-a.api.example.com`. ## Desventajas Cuando se utiliza el enrutamiento por nombres de host, los consumidores tienen que recordar diferentes nombres de host para interactuar con cada API que se exponga. Puede mitigar este problema proporcionando un SDK cliente. Sin embargo, los SDK cliente presentan sus propios desafíos. Por ejemplo, deben admitir actualizaciones continuas, varios idiomas, control de versiones, comunicación de cambios importantes causados por problemas de seguridad o la corrección de errores, la documentación, etc. Al utilizar el enrutamiento de nombres de host, también es necesario registrar el subdominio o el dominio cada vez que se crea un servicio nuevo. # Patrón de enrutamiento por rutas El enrutamiento por rutas es el mecanismo que consiste en agrupar varias o todas las API bajo el mismo nombre de host y utilizar un URI de solicitud para aislar los servicios; por ejemplo, `api.example.com/service-a` o `api.example.com/service-b`. ## Caso de uso típico La mayoría de los equipos optan por este método porque quieren una arquitectura sencilla: el desarrollador solo tiene que recordar una URL, como `api.example.com`, para poder interactuar con la API HTTP. La documentación de la API suele ser más fácil de digerir porque suele estar reunida en lugar de estar dividida en diferentes portales o archivos PDF. El enrutamiento basado en rutas se considera un mecanismo sencillo para compartir una API HTTP. Sin embargo, implica una sobrecarga operativa, como la configuración, la autorización, las integraciones y la latencia adicional debido a los múltiples saltos. También requiere procesos maduros de administración de cambios para garantizar que una mala configuración no interrumpa todos los servicios. En AWS, hay varias formas de compartir una API y dirigirla de manera efectiva al servicio correcto. En las siguientes secciones se analizan tres enfoques: proxy inverso del servicio HTTP, API Gateway y Amazon CloudFront. Ninguno de los enfoques sugeridos para unificar los servicios de API se basa en los servicios descendentes que se ejecutan en AWS. Los servicios podrían ejecutarse en cualquier lugar sin problemas o con cualquier tecnología, siempre que sean compatibles con HTTP. ## Proxy inverso del servicio HTTP Puede utilizar un servidor HTTP como [NGINX](https://www.f5.com/go/product/welcome-to-nginx) para crear configuraciones de enrutamiento dinámico. En una arquitectura de [Kubernetes](https://kubernetes.io/), también puede crear una regla de entrada que coincida con una ruta a un servicio. (Esta guía no cubre la entrada de Kubernetes; consulte la [documentación de Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource) para obtener más información). La siguiente configuración para NGINX asigna dinámicamente una solicitud HTTP de `api.example.com/my-service/` a `my-service.internal.api.example.com`. ``` server { listen 80; location (^/[\w-]+)/(.*) { proxy_pass $scheme://$1.internal.api.example.com/$2; } } ``` El siguiente diagrama ilustra el método de proxy inverso del servicio HTTP. ![\[Uso de un proxy inverso del servicio HTTP para el enrutamiento por rutas.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png) Este enfoque puede ser suficiente para algunos casos de uso en los que no se utilizan configuraciones adicionales para empezar a procesar las solicitudes, lo que permite que la API descendente recopile métricas y registros. Para prepararse para la producción operativa, querrá poder agregar observabilidad a todos los niveles de su pila, añadir configuraciones adicionales o agregar scripts para personalizar el punto de entrada de la API y permitir características más avanzadas, como la limitación de velocidad o los tokens de uso. ### Ventajas El objetivo final del método de proxy inverso del servicio HTTP es crear un enfoque escalable y administrable para unificar las API en un solo dominio, de forma que resulte coherente para cualquier consumidor de API. Este enfoque también permite a sus equipos de servicio implementar y administrar sus propias API, con una sobrecarga mínima después de la implementación. Los servicios administrados de AWS de rastreo, como [AWS X-Ray](https://aws.amazon.com/xray/) o [AWS WAF](https://aws.amazon.com/waf/), siguen siendo aplicables en este caso. ### Desventajas La principal desventaja de este enfoque son las exhaustivas pruebas y la administración de los componentes de la infraestructura que se requieren, aunque esto podría no ser un problema si se cuenta con equipos de ingeniería de confiabilidad del sitio (SRE). Este método supone un punto de inflexión en cuanto a los costos. En volúmenes bajos o medianos, es más caro que algunos de los otros métodos descritos en esta guía. En volúmenes altos, es muy rentable (alrededor de 100 000 transacciones por segundo o más). ## API Gateway El servicio [Amazon API Gateway](https://aws.amazon.com/api-gateway/) (API de REST y API HTTP) puede enrutar el tráfico de forma similar al método de proxy inverso del servicio HTTP. El uso de una puerta de enlace API en modo proxy HTTP proporciona una forma sencilla de agrupar muchos servicios en un punto de entrada al subdominio de nivel superior `api.example.com` y, a continuación, enviar las solicitudes por proxy al servicio anidado; por ejemplo, `billing.internal.api.example.com`. Probablemente no quiera ser demasiado detallado y asignar todas las rutas de todos los servicios en la puerta de enlace de API principal o raíz. En su lugar, opte por rutas comodín, por ejemplo, `/billing/*`, para reenviar las solicitudes al servicio de facturación. Al no asignar todas las rutas de la puerta de enlace de la API raíz o principal, se obtiene una mayor flexibilidad con respecto a las API, ya que no es necesario actualizar la puerta de enlace de la API raíz con cada cambio de API. ![\[Enrutamiento por rutas a través de API Gateway.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png) ### Ventajas Para controlar los flujos de trabajo más complejos, como el cambio de los atributos de las solicitudes, las API de REST exponen Apache Velocity Template Language (VTL) para poder modificar la solicitud y la respuesta. Las API de REST pueden ofrecer beneficios adicionales como los siguientes: + [Autenticación N/Z con AWS Identity and Access Management (IAM),](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) o [autorizadores de AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) + [AWS X-Ray para el rastreo](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html) + [Cómo integrar con AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) + [Limitación de velocidad básica](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + Tokens de uso para agrupar en buckets a los consumidores en diferentes niveles (consulte [Limitar las solicitudes de la API para mejorar el rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) en la documentación de API Gateway) ### Desventajas Con volúmenes altos, el costo puede ser un problema para algunos usuarios. ## CloudFront Puede utilizar la [característica de selección dinámica de orígenes](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html) de [Amazon CloudFront](https://aws.amazon.com/cloudfront/) para seleccionar condicionalmente un origen (un servicio) para reenviar la solicitud. Puede utilizar esta característica para enrutar varios servicios a través de un único nombre de host, por ejemplo, `api.example.com`. ### Caso de uso típico La lógica de enrutamiento forma parte del código de la función de Lambda@Edge, por lo que admite mecanismos de enrutamiento altamente personalizables, como las pruebas A/B, las versiones de valor controlado, la señalización de características y la reescritura de rutas. Esto se explica en el siguiente diagrama. ![\[Enrutamiento por rutas a través de CloudFront.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png) ### Ventajas Si necesita almacenar en caché las respuestas de la API, este método es una buena forma de unificar un conjunto de servicios en un único punto de conexión. Es un método rentable para unificar las colecciones de API. Además, CloudFront admite el [cifrado a nivel de campo](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html), así como la integración con AWS WAF para la limitación de velocidad básica y las ACL básicas. ### Desventajas Este método admite un máximo de 250 orígenes (servicios) que se pueden unificar. Este límite es suficiente para la mayoría de las implementaciones, pero puede provocar problemas con una gran cantidad de API a medida que amplíe su cartera de servicios. La actualización de las funciones de Lambda@Edge tarda unos minutos actualmente. CloudFront también tarda hasta 30 minutos en completar la propagación de los cambios a todos los puntos de presencia. En última instancia, esto bloquea las actualizaciones posteriores hasta que se completen. # Patrón de enrutamiento de encabezados HTTP El enrutamiento basado en encabezados le permite dirigirse al servicio correcto para cada solicitud especificando un encabezado HTTP en la solicitud HTTP. Por ejemplo, enviar el encabezado `x-service-a-action: get-thing` le permitiría ir a `get thing` desde `Service A`. La ruta de la solicitud sigue siendo importante, ya que ofrece orientación sobre el recurso en el que está intentando trabajar. Además de usar el enrutamiento de encabezados HTTP para las acciones, puede usarlo como un mecanismo para enrutar versiones, habilitar indicadores de características, pruebas A/B o necesidades similares. En realidad, es probable que utilice el enrutamiento de encabezados con uno de los otros métodos de enrutamiento para crear API sólidas. La arquitectura del enrutamiento de encabezados HTTP suele tener una capa de enrutamiento delgada delante de los microservicios que se enruta al servicio correcto y devuelve una respuesta, como se ilustra en el siguiente diagrama. Esta capa de enrutamiento podría cubrir todos los servicios o solo algunos servicios para permitir una operación como el enrutamiento basado en versiones. ![\[Enrutamiento de encabezados HTTP.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/cloud-design-patterns/images/routing-5.png) ## Ventajas Los cambios de configuración requieren un esfuerzo mínimo y se pueden automatizar fácilmente. Este método también es flexible y admite formas creativas de exponer solo las operaciones específicas que se desearían realizar en un servicio. ## Desventajas Al igual que con el método de enrutamiento por nombres de host, el enrutamiento de encabezados HTTP supone que usted tiene el control total sobre el cliente y puede manipular encabezados HTTP personalizados. Los proxies, las redes de entrega de contenido (CDN) y los equilibradores de carga pueden limitar el tamaño del encabezado. Aunque es poco probable que esto sea motivo de preocupación, podría ser un problema según el número de encabezados y cookies que agregue.