O que é rate limiting? HTTP 429 e como testar em APIs

Rate limiting

Também chamado de: rate limit, limite de requisições, limitação de taxa, throttling de API

Definição

Limitar quantas requisições um cliente pode fazer a uma API em uma janela de tempo, rejeitando o excesso, normalmente com 429 Too Many Requests e um header Retry-After.

O rate limiting (limitação de taxa) restringe com que frequência um cliente pode chamar uma API, por exemplo 100 requisições por minuto por API key. Requisições acima do limite são rejeitadas até a janela reiniciar. Isso protege o serviço contra sobrecarga e abuso, impede que um cliente barulhento prejudique os outros e desacelera ataques como tentativas de adivinhar senhas. O limite costuma ser controlado por API key, usuário, token ou endereço IP.

Exemplo

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests e Retry-After são HTTP padrão. Headers que informam a cota restante, como X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset, são uma convenção comum, mas não um padrão único, então verifique o que a documentação da sua API diz.

Algoritmos comuns

Janela fixa (fixed window): conta as requisições por minuto do relógio. É simples, mas um cliente pode mandar uma rajada dupla na virada de uma janela para a outra.
Janela deslizante (sliding window): conta as requisições dos últimos N segundos, o que suaviza esse efeito de fronteira.
Token bucket: os tokens são repostos a uma taxa constante e cada requisição gasta um, o que permite rajadas curtas até o tamanho do balde enquanto impõe uma taxa média.

O que testar

O próprio limite: envie limite + 1 requisições e verifique se exatamente a requisição excedente recebe 429.
Recuperação: depois do Retry-After ou do horário de reset, as requisições voltam a ter sucesso.
Escopo: o tráfego de um usuário ou de uma key não pode consumir a cota de outro. Verifique se os limites valem por key, por usuário ou por IP, e se um cliente consegue driblá-los trocando algo barato.
Endpoints sensíveis: login, redefinição de senha e verificação de OTP devem ter limites mais rígidos que leituras comuns.
Formato da resposta: uma requisição rejeitada retorna 429 com um corpo útil, e não um 500 ou uma conexão travada.
Comportamento do cliente: os seus próprios clientes fazem backoff e respeitam o Retry-After, em vez de repetir em um loop apertado.

Rate limits e a sua suíte de testes

Testes de API em paralelo e testes de carga podem estourar limites parecidos com os de produção e falhar por motivos que nada têm a ver com a mudança sob teste. Use keys dedicadas ou limites ampliados nos ambientes de teste e, quando um teste de carga tiver o objetivo de medir capacidade, garanta que você está medindo o serviço, e não o rate limiter.