Basisprincipes van rate limiting

Laten we de terminologie van snelheidsbeperking leren: aanvraagquota, tijdvensters en wat er gebeurt wanneer een client te veel aanvragen verstuurt.

Een aanvraagquotum is het maximale aantal aanvragen dat een API je toestaat — het aantal-gedeelte van een snelheidslimiet, dat de API tegen overbelasting beschermt.

Als je quotum 100 is, wordt aanvraag 101 geblokkeerd. Het quotum is je harde bovengrens, ongeacht hoe snel of langzaam je de aanvragen verstuurt.

Een tijdvenster is de periode waarop je quotum van toepassing is — het per-wat-gedeelte. Net als bij een bibliotheeklening wordt de teller opnieuw ingesteld wanneer het venster eindigt.

Combineer een quotum met een tijdvenster en je hebt een volledige snelheidslimiet: hoeveel aanvragen in welke periode — bijvoorbeeld 100 per minuut.

Achter de schermen telt de API je aanvragen in het huidige venster. Zodra de teller het quotum bereikt, worden verdere aanvragen geblokkeerd.

Overschrijd je je quotum binnen het venster, dan weigert de API de aanvraag in plaats van deze te verwerken — essentieel om te voorkomen dat iemand de service overspoelt.

Een geweigerde aanvraag waarvoor een snelheidslimiet geldt, retourneert HTTP 429 Te veel aanvragen — de standaardmanier waarop een API zegt dat je het rustiger aan moet doen omdat je de limiet hebt bereikt.

Een 429 wordt vaak geleverd met een Retry-After-header die precies aangeeft hoe lang je moet wachten — een aantal seconden of een specifieke datum.

Verwerk limieten als API-consument op een nette manier: herken 429-antwoorden, respecteer Retry-After en wacht voordat je het opnieuw probeert, in plaats van steeds nieuwe aanvragen te blijven sturen.

Samengevat: een aanvraagquotum plus een tijdvenster vormt een snelheidslimiet; bij overschrijding wordt HTTP 429 geretourneerd en geeft Retry-After aan wanneer je het opnieuw kunt proberen.