Saltar al contenido principal

Rate Limiting y Throttling

🎯 Objetivo​

Regla​

13.1: Se debe implementar rate limiting (limitación de tasa) y/o throttling (estrangulamiento) en la API para protegerla del abuso (intencional o no), asegurar la disponibilidad y garantizar un uso justo de los recursos. 13.2: La política de límites debe ser clara, comunicada y aplicada consistentemente.

📖 Concepto y Definición​

Regla​

13.3: Rate Limiting: Es la práctica obligatoria de controlar la cantidad de solicitudes que un cliente puede realizar a la API dentro de un período de tiempo específico. 13.4: Throttling: Es una técnica relacionada que suaviza el flujo de solicitudes, a menudo retrasando las que exceden un umbral en lugar de rechazarlas inmediatamente (aunque el término a veces se usa indistintamente con rate limiting). 13.5: El objetivo principal es prevenir que un solo cliente (o un grupo de clientes) sobrecargue la API, afectando su rendimiento o disponibilidad para otros usuarios.

Estrategias de Implementación Obligatorias:​

Regla​

13.6: Se debe implementar rate limiting basado en identificadores del cliente (ej. dirección IP, clave API, token de usuario autenticado). 13.7: Los límites deben definirse por cliente y por período de tiempo (ej. 100 solicitudes por minuto por clave API). 13.8: Cuando un cliente excede el límite de tasa, la API debe responder con el código de estado 429 Too Many Requests (Norma 4.4). 13.9: La respuesta 429 debe idealmente incluir el encabezado Retry-After, indicando cuánto tiempo (en segundos o como una fecha HTTP) el cliente debe esperar antes de volver a intentarlo. 13.10: La API puede (recomendado) incluir encabezados informativos en cada respuesta para indicar el estado actual de los límites del cliente:

  • X-RateLimit-Limit: El número total de solicitudes permitidas en la ventana de tiempo.
  • X-RateLimit-Remaining: El número de solicitudes restantes en la ventana actual.
  • X-RateLimit-Reset: La hora (en segundos Unix epoch o fecha HTTP) en que se reinicia la ventana de límite. Estos nombres de encabezado son una convención común y se recomienda su uso.

🤔 ¿Por qué es Importante? / Beneficios Clave (Contexto)​

  • Prevención de Abuso y DoS: Protege contra clientes maliciosos o con errores.
  • Disponibilidad y Estabilidad: Asegura que la API siga respondiendo bajo carga.
  • Uso Justo de Recursos: Evita que un cliente monopolice los recursos.
  • Control de Costos (Infraestructura): Ayuda a gestionar los costos asociados al tráfico.
  • Mejora la Predictibilidad del Rendimiento: Contribuye a un rendimiento más estable.

✅ Buenas Prácticas y Recomendaciones Clave​

Regla​

13.11: Se refuerzan las reglas 13.6 a 13.10: La implementación de rate limiting con respuesta 429 y encabezados informativos es obligatoria. 13.12: Los límites deben ser razonables y basarse en el caso de uso esperado de la API. Deben ser suficientemente altos para no impedir el uso legítimo, pero suficientemente bajos para proteger el servicio. 13.13: Se pueden definir diferentes límites para diferentes tipos de clientes (ej. usuarios anónimos vs. autenticados, diferentes niveles de suscripción) o diferentes endpoints (ej. endpoints más costosos pueden tener límites más bajos). 13.14: La política de rate limiting (límites, cómo se aplican, qué sucede al excederlos) debe estar claramente documentada (Norma 9.5). 13.15: La implementación debe ser eficiente para no añadir una sobrecarga significativa al procesamiento de cada solicitud. Se recomienda usar soluciones como cachés en memoria (Redis) con algoritmos eficientes (ej. token bucket, leaky bucket, fixed window, sliding window).

Don'ts (Prohibido):

  • 13.16: No se debe publicar una API sin alguna forma de rate limiting si se espera un uso significativo o si está expuesta públicamente.
  • 13.17: No se deben establecer límites excesivamente bajos que dificulten el uso legítimo.
  • 13.18: No se debe responder con 5xx (Error del Servidor) cuando se excede el límite de tasa; se debe usar 429.
  • 13.19: No se debe bloquear permanentemente a un cliente solo por exceder el límite temporalmente (a menos que sea parte de una política de abuso más amplia).

💡 Ejemplos Prácticos (Ilustrativos)​

Ejemplo 1: Respuesta Normal con Encabezados de Límite (Norma 13.10)​

HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Limit: 1000 // Límite por hora
X-RateLimit-Remaining: 950 // Solicitudes restantes
X-RateLimit-Reset: 1678880400 // Timestamp Unix de reinicio (ej. inicio de la próxima hora)

{
  // ... cuerpo de la respuesta ...
}

Ejemplo 2: Respuesta al Exceder el Límite (Norma 13.8, 13.9)​

HTTP/1.1 429 Too Many Requests
Content-Type: application/json // O application/problem+json
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1678880400
Retry-After: 35 // Esperar 35 segundos

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED", // Código de error estándar (Norma 11.4)
    "message": "Se ha excedido el límite de solicitudes permitidas."
  }
}

🛠️ Herramientas y Consideraciones Adicionales (Contexto)​

  • API Gateways: Muchos proveen funcionalidades de rate limiting configurables.
  • Proxies Inversos (Nginx, HAProxy): Pueden implementar rate limiting a nivel de infraestructura.
  • Bibliotecas de Frameworks: Existen bibliotecas para implementar rate limiting dentro de la aplicación (ej. express-rate-limit para Node.js, django-ratelimit para Django).
  • Algoritmos: Token Bucket y Leaky Bucket son populares para throttling y suavizado de tráfico. Fixed/Sliding Window son comunes para rate limiting estricto.
  • Monitorización: Es importante monitorizar el uso de la API y la frecuencia con la que se alcanzan los límites para ajustarlos si es necesario.