REST API frente a HTTP API y WebSocket API

Amazon API Gateway es un servicio totalmente administrado que le permite crear, publicar, proteger y supervisar API a cualquier escala. Actúa como la puerta de entrada a sus servicios de backend: funciones de Lambda, instancias de EC2, backends HTTP o cualquier servicio de AWS. API Gateway gestiona el tráfico, la autorización, la limitación de velocidad, la supervisión y el versionado de las API, para que su backend pueda centrarse en la lógica de negocio en lugar de ocuparse de la infraestructura de las API.

REST API (el producto original de API Gateway) ofrece el conjunto de funciones más amplio: transformación de solicitudes y respuestas mediante plantillas de mapeo, limitación de velocidad por método, planes de uso con claves de API, almacenamiento en caché de respuestas, integración con WAF, seguimiento con X-Ray, políticas de recursos y TLS mutuo mediante certificados de cliente. REST APIs admiten todos los tipos de integración: Lambda, HTTP, servicio de AWS, Mock y Lambda Proxy. Utilice REST API cuando necesite funciones avanzadas como transformación, almacenamiento en caché o planes de uso.

HTTP API se diseñó como una alternativa más sencilla, económica y rápida a REST API. Solo admite integraciones de Lambda proxy y HTTP proxy; no admite integraciones con servicios de AWS ni Mock. Entre sus principales ventajas se incluyen un coste hasta un 70 % inferior al de REST API, menor latencia, autorización JWT nativa integrada mediante OIDC y OAuth 2.0 (sin necesidad de un autorizador de Lambda en los escenarios de autenticación habituales) y la implementación automática. Si no necesita almacenamiento en caché, planes de uso ni transformación de solicitudes y respuestas, HTTP API es la mejor opción.

WebSocket API mantiene conexiones persistentes y bidireccionales entre los clientes y el servidor. A diferencia de HTTP (solicitud-respuesta), WebSocket permite que el servidor envíe mensajes a los clientes conectados en cualquier momento, sin que el cliente tenga que sondear. API Gateway administra las conexiones WebSocket y enruta los mensajes a funciones de Lambda según expresiones de ruta. Utilice WebSocket APIs para aplicaciones en tiempo real, como aplicaciones de chat, paneles en directo, edición colaborativa, videojuegos y cotizaciones bursátiles.

Las WebSocket APIs tienen tres rutas integradas: $connect (se activa cuando un cliente abre una conexión), $disconnect (se activa cuando se cierra una conexión) y $default (captura los mensajes que no coinciden con ninguna ruta). Puede añadir rutas personalizadas, como sendmessage, asignadas a funciones de Lambda específicas. Utilice la API de administración @connections para enviar mensajes a los clientes conectados desde su función de Lambda mediante el identificador de conexión del cliente.

Principales diferencias de un vistazo:

• REST API: conjunto completo de funciones (almacenamiento en caché, planes de uso, transformaciones y WAF), mayor coste y compatibilidad con todos los tipos de integración
• HTTP API: solo proxy de Lambda/HTTP, un 70 % más económica, autenticación JWT integrada, menor latencia y sin almacenamiento en caché ni planes de uso
• WebSocket API: conexiones bidireccionales persistentes, capacidad de envío desde el servidor y facturación por millón de mensajes y por minuto de tiempo de conexión

Para el examen SAA-C03: preguntas sobre HTTP sin tiempo real ni funciones avanzadas → HTTP API. Envío en tiempo real desde el servidor → WebSocket. Funciones complejas de API → REST API.

Las API de API Gateway se implementan en etapas (por ejemplo, dev, staging y prod). Cada etapa tiene su propia URL y configuración de limitación de velocidad, y puede hacer referencia a una instantánea de implementación específica. Utilice variables de etapa (similares a las variables de entorno) para parametrizar los endpoints de backend según la etapa; por ejemplo, puede dirigir la etapa dev a un alias de Lambda de desarrollo y prod al alias de producción sin duplicar la configuración de la API.

De forma predeterminada, las URL de API Gateway contienen el ID de la API (por ejemplo, abc123.execute-api.us-east-1.amazonaws.com). Para utilizarla en producción, cree un nombre de dominio personalizado respaldado por un certificado de ACM y asígnelo a su API y etapa. Utilice asignaciones de rutas base para alojar varias API bajo un mismo dominio (por ejemplo, api.example.com/orders → API Orders, api.example.com/users → API Users). Los nombres de dominio personalizados requieren un registro de alias de Route 53 que apunte al endpoint de API Gateway.

Las REST APIs pueden implementarse con tres tipos de endpoint: Edge-Optimised (front-end de CloudFront para distribución global, opción predeterminada), Regional (sin CloudFront, con menor latencia para clientes de la misma región o cuando añade su propio CloudFront) y Private (accesible únicamente desde su VPC mediante un endpoint de VPC de interfaz, para microservicios internos). Las HTTP APIs admiten Edge-Optimised y Regional. Las WebSocket APIs admiten Regional y Private. Elija Regional para las API utilizadas desde la misma región o cuando use distribuciones de CloudFront personalizadas.

Las REST APIs de API Gateway admiten implementaciones canary en una etapa. Puede dirigir un porcentaje del tráfico a una implementación canary (la nueva versión) mientras el resto se dirige a la implementación de producción. Supervise las tasas de error y la latencia de la canary; si se mantienen estables, promuévala al 100 %. Si surgen problemas, revierta el cambio estableciendo el peso de la canary en 0. Esto es similar al enrutamiento ponderado de alias de Lambda y permite actualizar las API de forma gradual y segura sin cambiar entre entornos blue/green.

Palabras clave de las preguntas del examen SAA-C03 para identificar el tipo de API: «API sencilla y rentable» → HTTP API; «bidireccional en tiempo real», «envío desde el servidor» o «chat» → WebSocket API; «transformación de solicitudes», «planes de uso», «limitación mediante claves de API» o «almacenamiento en caché de respuestas» → REST API. Cuando la pregunta simplemente consiste en «exponer Lambda como un endpoint HTTP de bajo coste», HTTP API es la opción adecuada. Cuando incluye funciones complejas de administración de API o socios, normalmente la respuesta correcta es REST API.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que REST API ofrece el conjunto completo de funciones de API Gateway (almacenamiento en caché, transformaciones, planes de uso y WAF) con un coste mayor; HTTP API es un 70 % más económica, incluye autenticación JWT integrada y ofrece menor latencia, por lo que es ideal para escenarios de proxy de Lambda/HTTP sin funciones avanzadas; y WebSocket API permite la comunicación en tiempo real con envío desde el servidor mediante conexiones persistentes para aplicaciones de chat, videojuegos y datos en directo. A continuación, exploraremos las integraciones de API Gateway con Lambda, backends HTTP y respuestas simuladas.