Comparar el mismo recorrido
Ejemplo ficticio con kilobytes decimales: 100 llamadas de 100 kB frente a 20 de 50 kB. El tráfico baja de 10000 a 1000 kB, un 90 %. Esto no demuestra una reducción equivalente de latencia. Solo se cuentan los cuerpos de respuesta, sin solicitudes ni cabeceras.
| Medida ficticia | Inicial | Candidato |
|---|---|---|
| Llamadas | 100 | 20 |
| Volumen por respuesta | 100 kB | 50 kB |
| Tráfico total | 10000 kB | 1000 kB |
| Duración del recorrido | Medir | Medir |
Reducir antes de paralelizar
- Solicite solo los campos necesarios y respete la paginación documentada. Los lotes necesitan límites y gestión de resultados parciales; una página mayor no siempre es más rápida.
- Reutilice conexiones y respuestas cuando el contexto y la frescura lo permitan. Limite la concurrencia y mida colas y trabajo del servidor.
- Defina plazo total y máximo de intentos. Espacie los reintentos transitorios con una parte aleatoria y compruebe qué capas ya reintentan.
Evitar repetir una acción completada
Un timeout del cliente no demuestra cancelación en el servidor. Antes de repetir una creación o pago, consulte su estado y el mecanismo de idempotencia del proveedor. Compare duración, errores y exactitud con carga representativa.
Fuentes primarias
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Inspeccionar el trabajo detrás de una respuesta de API.
Una sola consulta GraphQL puede desencadenar muchas llamadas posteriores. La latencia visible para el cliente puede ocultar el costo de los resolutores, las listas y las relaciones recorridas.
- Rastrear una operación desde el cliente hasta los servicios posteriores.
- Comparar el costo del campo con el volumen realmente útil.
- Vincular listas y consultas repetidas antes del almacenamiento en caché.
Fuente primaria: OWASP — GraphQL Cheat Sheet. Método relacionado: consultar la guía práctica.
Retry-After: espera, presupuesto y reintentos
Las notas detalladas de esta edición están disponibles en 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