Hetzelfde traject vergelijken
Fictief voorbeeld met decimale kilobytes: eerst 100 aanroepen met 100 kB per antwoord, daarna 20 met 50 kB. Het volume daalt van 10000 naar 1000 kB: 90 % minder. Dit bewijst geen even grote latentiedaling. Alleen antwoordinhoud telt mee, zonder verzoeken en headers.
| Fictieve meting | Oorspronkelijk | Kandidaat |
|---|---|---|
| Aanroepen | 100 | 20 |
| Data per antwoord | 100 kB | 50 kB |
| Totaal volume | 10000 kB | 1000 kB |
| Trajectduur | Meten | Meten |
Verminderen vóór parallelliseren
- Vraag alleen nodige velden op en volg de afgesproken paginering. Batches vereisen grenzen en verwerking van gedeeltelijke resultaten; grotere pagina’s zijn niet altijd sneller.
- Hergebruik verbindingen en antwoorden als context en actualiteit dat toelaten. Begrens gelijktijdigheid en meet ook serverwerk en wachtrijen.
- Stel een totale deadline en maximumaantal pogingen vast. Spreid herhalingen van tijdelijke fouten met willekeurige wachttijd; controleer herhalingen in alle lagen.
Voltooide acties niet dubbel uitvoeren
Een clienttimeout bewijst geen annulering op de server. Controleer vóór een nieuwe creatie of betaling de toestand en het aangeboden idempotentiemechanisme. Vergelijk duur, fouten en juistheid onder representatieve belasting.
Primaire bronnen
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Het werk achter één API-antwoord inspecteren.
Een enkele GraphQL-query kan veel downstream-aanroepen activeren. Client-zichtbare latentie kan de kosten van resolvers, lijsten en doorlopen relaties verbergen.
- Een bewerking traceren van client naar downstream-services.
- Veldkosten en daadwerkelijk nuttig volume vergelijken.
- Lijsten en herhaalde query's begrenzen vóór caching.
Primaire bron: OWASP — GraphQL Cheat Sheet. Verwante methode: lees de praktische gids.
Retry-After: wachten, budget en herhalen
De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.
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