Testing de Limites de Peticiones

Que Es Rate Limiting? #

Rate limiting controla cuantos requests un cliente puede hacer a una API dentro de una ventana de tiempo. Protege servidores del abuso, asegura uso justo y previene ataques de denegacion de servicio. Como tester, necesitas verificar que los rate limits estan correctamente implementados y que la API comunica los limites claramente.

Por Que Importa el Rate Limiting #

Sin rate limiting, un solo cliente podria sobrecargar el servidor. Escenarios del mundo real incluyen:

• Un bug en una app movil enviando requests en loop infinito
• Un usuario malicioso intentando extraer todos los datos
• Una integracion mal configurada haciendo miles de llamadas por segundo
• Ataques de fuerza bruta a endpoints de autenticacion

Algoritmos de Rate Limiting #

Ventana Fija (Fixed Window) #

Cuenta requests dentro de intervalos fijos (ej., por minuto comenzando en :00). Simple de implementar pero permite rafagas en los limites de ventana.

Ventana Deslizante (Sliding Window) #

Rastrea requests sobre una ventana de tiempo movil. Mas preciso que la ventana fija — si enviaste 80 requests en los ultimos 60 segundos, te quedan 20 sin importar los limites del reloj.

Token Bucket #

Los tokens se agregan al bucket a una tasa fija. Cada request consume un token. Si el bucket esta vacio, el request se rechaza. El bucket tiene capacidad maxima, permitiendo rafagas.

Leaky Bucket #

Los requests entran a una cola (bucket) y se procesan a tasa constante. Si el bucket se desborda, los nuevos requests se rechazan.

Headers de Rate Limit #

La mayoria de APIs comunican rate limits a traves de headers:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1625097600
Retry-After: 30

Testing de Headers de Rate Limit #

Para cada respuesta exitosa, verifica:

1. X-RateLimit-Limit esta presente y coincide con limites documentados
2. X-RateLimit-Remaining decrementa en 1 con cada request
3. X-RateLimit-Reset es un timestamp futuro valido
4. Los valores son consistentes entre requests secuenciales

Testing de Aplicacion de Rate Limit #

Test Basico de Aplicacion #

Envia requests en sucesion rapida y verifica:

import requests
import time

url = "https://api.example.com/data"
headers = {"Authorization": "Bearer token"}
results = []

for i in range(110):  # Exceder el limite de 100/min
    response = requests.get(url, headers=headers)
    results.append({
        "request": i + 1,
        "status": response.status_code,
        "remaining": response.headers.get("X-RateLimit-Remaining")
    })

# Verificar: primeros 100 deberian ser 200, resto 429

Escenarios de Test #

Test de Recuperacion de Rate Limit #

Despues de alcanzar el limite:

1. Verificar que 429 incluye Retry-After
2. Esperar la duracion especificada
3. Enviar otro request — deberia ser 200
4. Verificar que X-RateLimit-Remaining se reinicio

Limites por Endpoint vs. Globales #

Algunas APIs tienen diferentes limites por endpoint:

• Autenticacion: 5 requests/minuto (mas estricto)
• Operaciones de lectura: 1000 requests/minuto
• Operaciones de escritura: 100 requests/minuto
• Busqueda: 30 requests/minuto

Testea que los limites se aplican por endpoint y no se mezclan entre rutas.

Bugs Comunes de Rate Limiting #

Ejercicio Practico #

1. Testea limites de GitHub API: GitHub permite 60 requests/hora sin autenticacion. Envia requests a https://api.github.com/users y rastrea los headers de rate limit.
2. Mide la ventana: Determina si el rate limiter usa ventana fija o deslizante enviando rafagas en limites de ventana.
3. Test de recuperacion: Alcanza el rate limit, espera el Retry-After y verifica la recuperacion.
4. Documenta limites: Crea una tabla de todos los rate limits para una API de prueba.

Puntos Clave #

• Rate limiting protege APIs del abuso — testearlo es critico para produccion
• Algoritmos comunes: ventana fija, ventana deslizante, token bucket y leaky bucket
• Siempre verifica que los headers de rate limit sean precisos y consistentes
• Testea el ciclo completo: uso normal, alcanzar el limite, recibir 429 con Retry-After y recuperacion
• Los limites por endpoint, por usuario y por IP pueden diferir — testea cada uno independientemente