Comparar o mesmo percurso
Exemplo fictício em quilobytes decimais: 100 chamadas de 100 kB contra 20 de 50 kB. O tráfego desce de 10000 para 1000 kB, uma redução de 90 %. Isto não prova redução equivalente da latência. Contam-se apenas os corpos das respostas, sem pedidos nem cabeçalhos.
| Medida fictícia | Inicial | Candidato |
|---|---|---|
| Chamadas | 100 | 20 |
| Volume por resposta | 100 kB | 50 kB |
| Tráfego total | 10000 kB | 1000 kB |
| Duração do percurso | Medir | Medir |
Reduzir antes de paralelizar
- Pedir apenas os campos úteis e seguir a paginação documentada. Lotes precisam de limites e tratamento de resultados parciais; páginas maiores nem sempre são mais rápidas.
- Reutilizar ligações e respostas quando contexto e atualização permitirem. Limitar concorrência e medir filas e trabalho no servidor.
- Definir prazo total e máximo de tentativas. Espaçar novas tentativas de falhas transitórias com componente aleatória e verificar repetições nas várias camadas.
Evitar duplicar ações concluídas
Um timeout no cliente não prova cancelamento no servidor. Antes de repetir criação ou pagamento, verificar estado e mecanismo de idempotência previsto. Comparar duração, erros e exatidão com carga representativa.
Fontes primárias
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Inspecionar o trabalho por trás de uma resposta da API.
Uma única consulta GraphQL pode acionar muitas chamadas subsequentes. A latência visível para o cliente pode ocultar o custo de resolvers, listas e relacionamentos percorridos.
- Rastrear uma operação do cliente até os serviços subsequentes.
- Comparar o custo do campo com o volume realmente útil.
- Vincular listas e consultas repetidas antes do armazenamento em cache.
Fonte primária: OWASP — GraphQL Cheat Sheet. Método relacionado: consultar o guia prático.
Retry-After: espera, orçamento e repetição
As notas detalhadas desta edição estão disponíveis em inglês.
Reducing API calls includes controlling repetition
An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.
- Trace SDK and proxy retries under one logical identifier.
- Avoid shortening server instructions merely to fit a budget.
- Verify an uncertain write’s state before creating a new intention.
Explore Retry-After and the retry model →
References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS