API Gateway vs. Reverse Proxy: Diferencias y casos de uso

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

API Gateway y Reverse Proxy suelen confundirse porque ambos se sitúan entre el cliente y el servidor, reenviando solicitudes. Sin embargo, resuelven problemas distintos en niveles de abstracción diferentes. Si no comprendes la diferencia, terminarás metiendo lógica innecesaria en la capa equivocada o renunciando a funcionalidades que realmente necesitas.

¿Qué es un Reverse Proxy?

Un Reverse Proxy es un servidor que se posiciona entre los clientes y uno o varios servidores backend, reenviando las solicitudes entrantes hacia esos servidores. Desde la perspectiva del cliente, el Reverse Proxy parece ser el servidor real; el cliente desconoce qué instancia backend está procesando realmente su solicitud.

El término “Reverse” tiene un significado específico: mientras que un Forward Proxy trabaja para el cliente y reenvía solicitudes hacia el exterior, el Reverse Proxy trabaja para el servidor y recibe solicitudes del exterior.

Funciones principales de un Reverse Proxy

• Routing: Reenvía solicitudes a diferentes servidores backend según rutas URL u nombres de dominio
• Load Balancing: Distribuye las solicitudes entre múltiples instancias backend (Round-Robin, Least-Connections, IP-Hash)
• TLS Termination: Finaliza la conexión SSL/TLS en el proxy; el backend se comunica sin cifrado dentro de la red interna
• Caching: Almacena en caché contenido estático o respuestas API
• Compression: Comprime respuestas (gzip, brotli) antes de enviarlas al cliente
• Rate Limiting: Aplicar límites simples de solicitudes por IP
• Health Checks: Supervisa los servidores backend y los retira del pool si fallan

Soluciones de Reverse Proxy conocidas

• Nginx: El Reverse Proxy más extendido, altamente performante y configurable
• HAProxy: Especializado en Load Balancing, tanto a nivel TCP como HTTP
• Apache con mod_proxy: Servidor web clásico con funcionalidad de proxy
• Traefik: Reverse Proxy moderno, nativo para la nube, con Service Discovery automático
• Caddy: Reverse Proxy fácil de configurar con TLS automático

¿Qué es un API Gateway?

Un API Gateway es una forma especializada del Reverse Proxy que ofrece funcionalidades adicionales específicas para API. Se sitúa en la entrada de la infraestructura de API y gestiona, protege y orquesta todo el tráfico de la API.

Mientras que un Reverse Proxy opera a nivel HTTP (rutas, nombres de dominio, headers), un API Gateway opera a nivel de API (endpoints, API-Keys, OAuth-Tokens, cuotas, versiones de API).

Funciones principales de un API Gateway (más allá del Reverse Proxy)

• Autenticación y Autorización: OAuth 2.0, validación JWT, verificación de API-Key en cada endpoint
• Rate Limiting específico de API: Cuotas por API-Key, por usuario, por endpoint, no solo por IP
• Transformación Request/Response: Convierte payloads, añade headers, mapea versiones
• Versionado de API: Enruta /v1/users y /v2/users a diferentes backends o versiones
• Agregación de solicitudes: Combina múltiples llamadas backend en una única solicitud del cliente (composición de API)
• Traducción de protocolos: REST a gRPC, SOAP a REST, WebSocket a HTTP
• Analítica y monitoreo de API: Métricas detalladas por endpoint, por consumidor, por API
• Integración con Developer Portal: Documentación de API, auto-registro, gestión de claves
• Circuit Breaker: Devuelve automáticamente respuestas de error en caso de fallo backend, en lugar de esperar timeouts
• Mocking: Simula endpoints para desarrollo y testing

Soluciones de API Gateway conocidas

• Kong: API Gateway de código abierto con sistema de plugins, basado en Nginx/OpenResty
• AWS API Gateway: Solución en la nube, profundamente integrada en el ecosistema AWS
• Apigee: Gestión de API de Google Cloud, enfoque empresarial
• Tyk: Código abierto, ligero, basado en Go
• KrakenD: API Gateway de alto rendimiento con enfoque en agregación
• Azure API Management: Solución en la nube de Microsoft con Developer Portal

La diferencia esencial

La distinción se puede reducir a una fórmula:

Reverse Proxy = Capa de infraestructura (HTTP, TCP, Routing, Load Balancing) API Gateway = Capa de API (Endpoints, Autenticación, Cuotas, Transformación, Analítica)

Un Reverse Proxy se pregunta: ¿Cuál servidor debería procesar esta solicitud? Un API Gateway se pregunta: ¿Está autorizado este cliente para llamar a este endpoint, y cuánta cuota le queda hoy?

Tabla comparativa

¿Quién usa qué?

• Reverse Proxy: Administradores de sistemas, ingenieros DevOps que necesitan distribuir tráfico y centralizar TLS
• API Gateway: Equipos de API, equipos de plataforma que necesitan gestionar, asegurar y monetizar APIs

¿Por qué es importante este tema en informática y exámenes?

En exámenes de arquitectura y certificaciones (AWS Solutions Architect, Azure API Management) regularmente se pregunta sobre la diferencia. En la práctica, la falta de conocimiento lleva a errores arquitectónicos: la lógica de autenticación se coloca en Reverse Proxies (donde no pertenece), o los API Gateways se utilizan como simples balanceadores de carga (desperdicio de funcionalidad). La asignación correcta de responsabilidades es un signo de madurez arquitectónica.

¿Por qué es importante este tema en la práctica?

Escenario 1: Arquitectura de Microservicios

En una arquitectura de microservicios con 20 servicios necesitas ambos: el Reverse Proxy (por ejemplo, Nginx/Envoy) para Load Balancing y TLS dentro del cluster, y el API Gateway (por ejemplo, Kong) como entrada pública para clientes externos con autenticación, cuotas y versionado.

Escenario 2: Monolito con API

Un único servidor backend con una API REST a menudo solo necesita un Reverse Proxy (Nginx) para TLS y caching. Un API Gateway sería sobre-ingeniería.

Escenario 3: Plataforma multi-cliente

Una plataforma con aplicación web, aplicación móvil y clientes B2B API necesita un API Gateway, porque cada tipo de cliente tiene diferentes métodos de autenticación, cuotas y campos requeridos. Un Reverse Proxy aquí no es suficiente.

Ejemplo práctico: Nginx como Reverse Proxy vs. Kong como API Gateway

Este ejemplo muestra el mismo requisito (asegurar un endpoint /users) tanto con Nginx como Reverse Proxy como con Kong como API Gateway. La comparación ilustra la diferencia en nivel de abstracción y funcionalidad.

Nginx como Reverse Proxy

# nginx.conf — Configuración de Reverse Proxy
# Reenvía solicitudes a servidores backend, con TLS y Rate Limiting

upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    # Load Balancing: Round-Robin (por defecto)
    # Least-Connections: least_conn;
    # IP-Hash (Session-Stickiness): ip_hash;
}

# Zona de Rate Limiting: 10 solicitudes por segundo por IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    listen 443 ssl;
    server_name api.example.com;

    # TLS Termination
    ssl_certificate /etc/ssl/certs/api.crt;
    ssl_certificate_key /etc/ssl/private/api.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    # /users -> Backend
    location /users {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # /orders -> otro servidor backend
    location /orders {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://10.0.0.3:3001;
        proxy_set_header Host $host;
    }

    # Endpoint de Health Check
    location /health {
        return 200 "OK";
        add_header Content-Type text/plain;
    }
}

Kong como API Gateway

# kong.yml — Configuración declarativa
# Define servicios, rutas y plugins (autenticación, rate limiting, análisis)

services:
  - name: user-service
    url: http://10.0.0.1:3000
    routes:
      - name: users-route
        paths:
          - /users
        methods:
          - GET
          - POST
          - PUT
          - DELETE
        # Versionado de API mediante headers
        strip_path: false

  - name: order-service
    url: http://10.0.0.3:3001
    routes:
      - name: orders-route
        paths:
          - /orders
        methods:
          - GET
          - POST

plugins:
  # Autenticación JWT para todas las rutas
  - name: jwt
    config:
      secret_is_base64: false
      run_on_preflight: true

  # Rate limiting por consumidor (no solo por IP)
  - name: rate-limiting
    config:
      minute: 100
      hour: 1000
      policy: redis
      redis_host: redis.internal
      limit_by: consumer
      fault_tolerant: true

  # Configuración CORS
  - name: cors
    config:
      origins:
        - https://app.example.com
      methods:
        - GET
        - POST
        - PUT
        - DELETE
      headers:
        - Authorization
        - Content-Type
      credentials: true

  # Métricas de Prometheus para análisis de API
  - name: prometheus
    config:
      per_consumer: true

consumers:
  - username: mobile-app
    jwt_secrets:
      - key: mobile-app-key
        secret: mobile-app-secret-2026
  - username: web-app
    jwt_secrets:
      - key: web-app-key
        secret: web-app-secret-2026

La diferencia es evidente: Nginx configura enrutamiento HTTP y rate limiting basado en IP. Kong configura enrutamiento de API con autenticación JWT, rate limiting por consumidor, CORS y métricas, todo de forma declarativa y por endpoint de API.

Información detallada

¿Puede un API Gateway reemplazar un Reverse Proxy?

Sí y no. Un API Gateway como Kong a menudo se basa en un Reverse Proxy (Kong utiliza Nginx/OpenResty internamente). Ofrece todas las funciones de Reverse Proxy más capacidades de API. En muchas arquitecturas, el API Gateway reemplaza el Reverse Proxy para el tráfico externo. Internamente, entre microservicios, suele permanecer activo un Reverse Proxy separado o un Service Mesh (Envoy, Linkerd).

¿Cuándo es suficiente un Reverse Proxy?

• Una única API o monolito
• Pocos endpoints, sin versionado de API
• Autenticación implementada en el backend (sin necesidad de autenticación centralizada)
• Sin cuotas diferenciadas por cliente
• Equipo pequeño e infraestructura limitada

¿Cuándo necesitas un API Gateway?

• Múltiples APIs o microservicios tras un único punto de entrada
• Autenticación centralizada (OAuth, JWT) para todas las APIs
• Cuotas y rate limits diferenciados por cliente/API
• Versionado y migración de API
• Agregación de solicitudes (una llamada del cliente a múltiples llamadas del backend)
• Análisis de API y monetización
• Developer Portal para autoservicio

Reverse Proxy vs. Load Balancer vs. API Gateway

Estos tres términos se confunden frecuentemente:

• Load Balancer: Distribuye tráfico en múltiples servidores (Layer 4, TCP/UDP). Enfoque: disponibilidad. Ejemplos: HAProxy, AWS ALB.
• Reverse Proxy: Reenvía solicitudes HTTP, TLS, caching (Layer 7). Enfoque: infraestructura. Ejemplos: Nginx, Caddy.
• API Gateway: Reverse Proxy con funciones de API Management. Enfoque: gobierno de API. Ejemplos: Kong, AWS API Gateway.

Un Load Balancer puede ser parte de un Reverse Proxy. Un Reverse Proxy puede ser parte de un API Gateway. El nivel de abstracción aumenta desde LB pasando por RP hasta AG.

Service Mesh vs. API Gateway

Un Service Mesh (Istio, Linkerd) gestiona la comunicación entre microservicios (internamente), mientras que un API Gateway gestiona el tráfico externo. En arquitecturas modernas coexisten ambos: API Gateway externamente, Service Mesh internamente. Envoy puede asumir ambos roles.

Preguntas frecuentes: API Gateway vs. Reverse Proxy

Continúa tu aprendizaje en APIs

El siguiente artículo aborda API Gateway Sicherheit — cómo configurar centralmente la autenticación, rate limiting y protección contra amenazas en tu API Gateway.

Referencias y recursos adicionales

1. https://nginx.org/en/docs/
2. https://docs.konghq.com/
3. https://learn.microsoft.com/en-us/azure/api-management/
4. https://docs.aws.amazon.com/apigateway/
5. https://www.martinfowler.com/articles/richardson-maturity-model.html

Libros recomendados para desarrollo de APIs

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert