Causa: Retry sem Retry-After e jitter
Melhoria: Respeite Retry-After, use backoff exponencial e limite total de tentativas.
JSON, erros e rate limiting
Formato de dados, contrato de falha e proteção de capacidade
Objetivo
Validar JSON, projetar erros acionáveis e impedir que retries ou clientes ruidosos derrubem a API.
História
Mil ordens em uma resposta continuam sendo uma requisição HTTP, mas aumentam bytes, memória, tempo de consulta e trabalho do cliente. Paginação controla esse custo sem fingir que a contagem de requisições é a única métrica.
Hipótese a testar
Dez usuários podem custar mais que mil ordens se cada usuário acionar consultas caras e repetidas; volume precisa ser medido em várias dimensões.
Pré-requisitos
- HTTP
- JSON
- listas
Simulador
Altere uma variável, antecipe o efeito e compare com o indicador. A escala mostra pressão relativa, não uma garantia de segurança.
Faixa controladaReveja o contrato e os testes antes de concluir.
Fluxo observado
- entrada JSON
- schema
- autorização
- consulta paginada
- limite
- resposta + metadados
O que observar
- JSON transporta dados; Java, Python ou TypeScript executam código em cada lado.
- 400 indica requisição malformada; 422 pode representar dados bem formados que violam regra.
- Rate limit deve considerar identidade, operação, custo e capacidade, não somente IP.
Erros comuns e melhoria
Causa: Sem paginação ou projeção de campos
Melhoria: Use cursor, limite máximo e representação resumida.
Exercício guiado
- Defina schema de erro com code, message, field e traceId.
- Compare 10 usuários e 1000 ordens nas métricas de bytes, CPU e consultas.
- Implemente resposta 429 conceitual com Retry-After.
Desafio independente
Defina limites diferentes para busca simples, exportação e upload de fotos, justificando custo e experiência.
Evidência exigida
Contrato OpenAPI ou tabela equivalente para sucesso, validação, autenticação, autorização, limite e falha interna.