En resumen
Implemente la limitación de tasa de API utilizando algoritmos de cubo de fichas (token bucket) o ventana deslizante. Devuelva los encabezados estándar de limitación de tasa del IETF (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset) y 429 Demasiadas Solicitudes cuando se superen los límites. Modern PetstoreAPI implementa la limitación de tasa con cuotas por usuario y respuestas de error claras.
Introducción
Un cliente realiza 10.000 solicitudes a su API en un minuto. Su base de datos se bloquea. Sus alertas de monitoreo se disparan. Sus otros clientes no pueden acceder a la API. Está bajo ataque, o tal vez simplemente lidiando con un cliente defectuoso en un bucle de reintentos.
La limitación de tasa evita esto. Establece un límite en la cantidad de solicitudes que un cliente puede realizar en un período de tiempo. Cuando exceden el límite, se devuelve 429 Demasiadas Solicitudes. El cliente se retira, y su API se mantiene saludable.
El antiguo Swagger Petstore no implementa ninguna limitación de tasa. Modern PetstoreAPI implementa la limitación de tasa con encabezados IETF estándar, cuotas por usuario y respuestas de error claras.
En esta guía, aprenderá sobre algoritmos de limitación de tasa, encabezados estándar y cómo Modern PetstoreAPI implementa la limitación de tasa correctamente.
Por qué las APIs Necesitan Limitación de Tasa
La limitación de tasa protege su API del abuso y asegura un uso justo.
Protección contra el Abuso
1. Ataques de Denegación de Servicio (DoS)
Un atacante inunda su API con solicitudes para dejarla no disponible. La limitación de tasa limita su impacto.
2. Relleno de credenciales (Credential stuffing)
Los atacantes intentan miles de combinaciones de nombre de usuario/contraseña. La limitación de tasa los ralentiza.
3. Extracción de datos (Data scraping)
Los bots extraen todo su conjunto de datos. La limitación de tasa hace que la extracción sea poco práctica.
4. Control de costos
Si su API llama a servicios costosos (modelos de IA, APIs de terceros), la limitación de tasa previene costos descontrolados.
Uso Justo
1. Evitar que un cliente monopolice los recursos
Sin limitación de tasa, un cliente que realiza 1000 solicitudes/seg puede dejar sin recursos a otros clientes.
2. Rendimiento predecible
La limitación de tasa asegura tiempos de respuesta consistentes para todos los clientes.
3. Acceso por niveles
Nivel gratuito: 100 solicitudes/hora. Nivel de pago: 10.000 solicitudes/hora. La limitación de tasa aplica estos niveles.
Beneficios Operativos
1. Planificación de capacidad
Usted conoce la carga máxima que manejará su API.
2. Previsibilidad de costos
Los límites de tasa restringen los costos de infraestructura.
3. Degradación elegante
Bajo carga, la limitación de tasa previene fallas en cascada.
Algoritmos de Limitación de Tasa
Diferentes algoritmos tienen diferentes compensaciones.
1. Ventana Fija
Cuenta las solicitudes en ventanas de tiempo fijas.
Cómo funciona:
Window 1 (00:00-00:59): 100 requests allowed
Window 2 (01:00-01:59): 100 requests allowed
Implementación:
def is_allowed(user_id):
current_minute = get_current_minute()
key = f"rate_limit:{user_id}:{current_minute}"
count = redis.incr(key)
redis.expire(key, 60)
return count <= 100
Ventajas:
- Fácil de implementar
- Bajo uso de memoria
Desventajas:
- Problema de ráfaga: El cliente puede hacer 100 solicitudes a las 00:59 y 100 a la 01:00 (200 en 2 segundos)
2. Ventana Deslizante
Cuenta las solicitudes en una ventana de tiempo móvil.
Cómo funciona:
A la 01:30, cuenta las solicitudes desde las 00:30 hasta la 01:30 (últimos 60 minutos).
Implementación:
def is_allowed(user_id):
now = time.time()
window_start = now - 3600 # 1 hour ago
key = f"rate_limit:{user_id}"
# Remove old requests
redis.zremrangebyscore(key, 0, window_start)
# Count requests in window
count = redis.zcard(key)
if count < 100:
redis.zadd(key, {now: now})
redis.expire(key, 3600)
return True
return False
Ventajas:
- No hay problema de ráfaga
- Limitación de tasa precisa
Desventajas:
- Mayor uso de memoria (almacena la marca de tiempo para cada solicitud)
- Más complejo
3. Cubo de Fichas (Token Bucket)
Los fichas se añaden a un cubo a una tasa fija. Cada solicitud consume un ficha.
Cómo funciona:
Bucket capacity: 100 tokens
Refill rate: 10 tokens/second
Request: consumes 1 token
Implementación:
def is_allowed(user_id):
now = time.time()
key = f"rate_limit:{user_id}"
# Get current state
data = redis.hgetall(key)
tokens = float(data.get('tokens', 100))
last_refill = float(data.get('last_refill', now))
# Refill tokens
elapsed = now - last_refill
tokens = min(100, tokens + elapsed * 10) # 10 tokens/sec
if tokens >= 1:
tokens -= 1
redis.hset(key, 'tokens', tokens)
redis.hset(key, 'last_refill', now)
redis.expire(key, 3600)
return True
return False
Ventajas:
- Permite ráfagas (hasta la capacidad del cubo)
- Limitación de tasa suave
- Estándar de la industria
Desventajas:
- Más complejo que la ventana fija
- Requiere almacenar estado
4. Cubo con Fugas (Leaky Bucket)
Las solicitudes se añaden a una cola y se procesan a una tasa fija.
Cómo funciona:
Queue capacity: 100 requests
Process rate: 10 requests/second
Ventajas:
- Tasa de salida suave
- Bueno para proteger servicios posteriores
Desventajas:
- Añade latencia (las solicitudes esperan en la cola)
- Complejo de implementar
¿Qué Algoritmo Usar?
Para la mayoría de las APIs: Cubo de Fichas (Token Bucket)
Es el estándar de la industria, permite ráfagas razonables y proporciona una limitación de tasa suave.
Modern PetstoreAPI utiliza el cubo de fichas con cuotas por usuario.
Encabezados Estándar de Limitación de Tasa
Utilice los encabezados estándar del IETF (draft-ietf-httpapi-ratelimit-headers).
Encabezados Estándar
RateLimit-Limit: Número máximo de solicitudes permitidas en el período de tiempo
RateLimit-Limit: 100
RateLimit-Remaining: Solicitudes restantes en la ventana actual
RateLimit-Remaining: 45
RateLimit-Reset: Segundos hasta que se reinicie el límite de tasa
RateLimit-Reset: 3600
Ejemplo de Respuesta
GET /pets
200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 99
RateLimit-Reset: 3600
{
"data": [...]
}
Encabezados Heredados (Obsoletos)
Muchas APIs utilizan encabezados no estándar:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 99
X-RateLimit-Reset: 1710331200
No utilice estos. El prefijo X- está obsoleto y el formato no está estandarizado.
Cómo Modern PetstoreAPI Implementa la Limitación de Tasa
Modern PetstoreAPI implementa la limitación de tasa de cubo de fichas con encabezados estándar.
Límites de Tasa por Nivel
Nivel gratuito:
- 100 solicitudes/hora
- 1.000 solicitudes/día
Nivel Pro:
- 10.000 solicitudes/hora
- 100.000 solicitudes/día
Nivel Empresarial:
- Límites personalizados
Implementación
Solicitud exitosa:
GET /v1/pets
200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 99
RateLimit-Reset: 3540
{
"data": [...]
}
Límite de tasa excedido:
GET /v1/pets
429 Too Many Requests
Content-Type: application/problem+json
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 120
Retry-After: 120
{
"type": "https://petstoreapi.com/errors/rate-limit-exceeded",
"title": "Rate Limit Exceeded",
"status": 429,
"detail": "You have exceeded the rate limit of 100 requests per hour",
"instance": "/v1/pets",
"retryAfter": 120,
"limit": 100,
"window": "1h"
}
Por Usuario vs Por IP
Por usuario (solicitudes autenticadas):
Límite de tasa por ID de usuario o clave API. Más preciso y justo.
user_id = get_authenticated_user()
is_allowed(user_id)
Por IP (solicitudes no autenticadas):
Límite de tasa por dirección IP. Menos preciso (IPs compartidas, VPNs) pero mejor que nada.
ip_address = request.remote_addr
is_allowed(ip_address)
Modern PetstoreAPI utiliza la limitación de tasa por usuario para solicitudes autenticadas y por IP para puntos finales públicos.
Formato de Respuesta de Limitación de Tasa
Cuando se exceden los límites de tasa, devuelva 429 con el formato de error RFC 9457.
Estructura de la Respuesta
{
"type": "https://petstoreapi.com/errors/rate-limit-exceeded",
"title": "Rate Limit Exceeded",
"status": 429,
"detail": "You have exceeded your rate limit. Please try again later.",
"instance": "/v1/pets",
"retryAfter": 120,
"limit": 100,
"remaining": 0,
"reset": 120,
"window": "1h"
}
Encabezados
429 Too Many Requests
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 120
Retry-After: 120
Retry-After: Indica a los clientes cuándo reintentar (en segundos).
Probando la Limitación de Tasa con Apidog
Apidog le ayuda a probar el comportamiento de limitación de tasa.
Escenarios de Prueba
1. Uso normal:
Enviar 50 solicitudes → Todas exitosas
Verificar que RateLimit-Remaining disminuye
2. Exceder límite:
Enviar 101 solicitudes → la 101ª devuelve 429
Verificar el formato de respuesta de error
Comprobar el encabezado Retry-After
3. Comportamiento de reinicio:
Exceder el límite → Esperar el reinicio → Verificar que el límite se ha restaurado
4. Diferentes niveles:
Probar el nivel gratuito (100/hora)
Probar el nivel pro (10.000/hora)
Verificar que los límites se aplican correctamente
Ejemplo de Prueba con Apidog
// Test rate limit headers
pm.test("Rate limit headers present", () => {
pm.response.to.have.header("RateLimit-Limit");
pm.response.to.have.header("RateLimit-Remaining");
pm.response.to.have.header("RateLimit-Reset");
});
// Test rate limit exceeded
pm.test("Returns 429 when limit exceeded", () => {
// Make 101 requests
for (let i = 0; i < 101; i++) {
pm.sendRequest("GET /v1/pets");
}
pm.response.to.have.status(429);
});
Mejores Prácticas de Limitación de Tasa
1. Usar encabezados estándar
Utilice los encabezados estándar del IETF, no los encabezados personalizados X-.
2. Devolver 429, no 403
429 significa "demasiadas solicitudes". 403 significa "prohibido". No los confunda.
3. Incluir Retry-After
Indique a los clientes cuándo pueden reintentar.
4. Documentar sus límites
Haga visibles los límites de tasa en la documentación.
5. Proporcionar diferentes niveles
Nivel gratuito: límites bajos. Nivel de pago: límites más altos.
6. Limitar la tasa por usuario, no por IP
Los límites por usuario son más precisos y justos.
7. Permitir ráfagas
El cubo de fichas permite ráfagas razonables sin penalizar el uso normal.
8. Monitorear los impactos de limitación de tasa
Rastree con qué frecuencia los clientes alcanzan los límites de tasa. Las tasas altas indican problemas.
9. Proporcionar un punto final de estado de limitación de tasa
GET /v1/rate-limit
200 OK
{
"limit": 100,
"remaining": 45,
"reset": 3540
}
10. Probar la limitación de tasa
Utilice Apidog para probar el comportamiento de limitación de tasa antes de la implementación.
Conclusión
La limitación de tasa protege su API del abuso y asegura un uso justo. Utilice el algoritmo de cubo de fichas con encabezados IETF estándar (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset). Devuelva 429 Demasiadas Solicitudes con el formato de error RFC 9457 cuando se excedan los límites.
Modern PetstoreAPI implementa la limitación de tasa correctamente con cuotas por usuario, encabezados estándar y respuestas de error claras. Consulte la documentación para obtener detalles de implementación.
Pruebe su limitación de tasa con Apidog para asegurar que funciona correctamente bajo carga y maneja los casos extremos de forma adecuada.
Preguntas Frecuentes
¿Qué límites de tasa debo establecer?
Comience de forma conservadora: 100 solicitudes/hora para el nivel gratuito, 10.000/hora para el de pago. Ajuste según los patrones de uso y la capacidad de la infraestructura.
¿Debo limitar la tasa por IP o por usuario?
Limite la tasa por usuario (clave API) para solicitudes autenticadas. Utilice la limitación de tasa basada en IP solo para puntos finales públicos.
¿Qué sucede si un cliente excede el límite de tasa?
Devuelva 429 Demasiadas Solicitudes con el encabezado Retry-After. No bloquee al cliente permanentemente, permítale reintentar después de que se reinicie la ventana.
¿Cómo manejo los límites de tasa para webhooks?
Los webhooks son de servidor a servidor, por lo que los límites de tasa deben ser más altos. Considere límites separados para webhooks frente a llamadas a la API.
¿Debo limitar la tasa de servicios internos?
Sí, pero con límites mucho más altos. La limitación de tasa previene fallas en cascada incluso en sistemas internos.
¿Cómo pruebo la limitación de tasa?
Utilice Apidog para enviar múltiples solicitudes y verificar las respuestas 429, los encabezados de limitación de tasa y el comportamiento de reinicio.
¿Qué pasa si mi API está detrás de una CDN?
El almacenamiento en caché de la CDN reduce la carga, pero aún necesita limitación de tasa para fallos de caché y solicitudes POST/PUT/DELETE.
¿Cómo implemento la limitación de tasa en múltiples servidores?
Utilice un almacén de datos compartido (Redis, Memcached) para rastrear los límites de tasa en todos los servidores. No utilice memoria local, no funcionará en sistemas distribuidos.