Hoe om te gaan met snelheidsbeperking

Snelheidsbeperking is een veelgebruikte techniek die door API-providers wordt gebruikt voor het beheren van het aantal aanvragen dat in een specifieke periode aan hun service kan worden gedaan. API-providers gebruiken snelheidsbeperking om ervoor te zorgen dat hun service beschikbaar blijft en reageert op alle gebruikers en om misbruik of overgebruik van de service te voorkomen.

Wanneer u cloud-API's in uw toepassing gebruikt, moet u hun frequentielimieten begrijpen. De volgende technieken kunnen u helpen bij het afhandelen van snelheidsbeperking in uw toepassingen:

  • Begrijp limieten voor verwerkingssnelheid. Raadpleeg de documentatie van de API die u gebruikt om inzicht te hebben in de frequentielimieten. Frequentielimieten kunnen afhankelijk zijn van de API-provider of het serviceplan dat u gebruikt. Sommige API's kunnen bijvoorbeeld verschillende tarieflimieten hebben voor gratis en betaalde abonnementen.
  • Gebruik informatie over snelheidsbeperking. API's die frequentielimieten gebruiken, communiceren doorgaans de huidige limieten in de antwoordheaders. De RateLimit-Remaining header geeft bijvoorbeeld het aantal aanvragen aan dat in het huidige venster blijft. Als u een antwoord ontvangt met deze header ingesteld op 0, weet u dat u de frequentielimiet hebt bereikt en moet wachten op het volgende venster voordat u een andere aanvraag verzendt. De RateLimit-Reset header geeft de tijd aan waarop de frequentielimiet opnieuw wordt ingesteld. Headernamen en indelingen verschillen per API: GitHub, bijvoorbeeld gebruikt x-ratelimit-remaining en x-ratelimit-reset in UTC epoch seconden. Sommige API's verzenden de headers pas nadat u een drempelwaarde hebt bereikt. Een voorbeeld is wanneer u 10% van de aanvragen over hebt.
  • API-gebruik optimaliseren. Sommige services wijzen verschillende kosten toe aan verschillende aanvragen op basis van hun complexiteit. Sommige API's kunnen bijvoorbeeld meer kosten in rekening brengen voor aanvragen die meer gegevens retourneren. Als u de kosten van uw toepassing wilt verlagen, optimaliseert u uw API-gebruik door alleen de gegevens op te halen die u nodig hebt. Batchaanvragen gebruiken als de API deze ondersteunt. Ze helpen u het aantal resources te verminderen dat nodig is om het antwoord te verwerken en binnen de frequentielimieten te blijven.
  • Implementeer een lokale snelheidsbegrenzer. Implementeer een frequentielimiet binnen de toepassing zelf om het aantal aanvragen te beperken dat in een specifieke periode aan de API kan worden gedaan. U kunt dit doen door technieken zoals de token bucket- of leaky bucket-algoritmen te gebruiken, waarmee de toepassing veel aanvragen per tijdsperiode kan indienen. Extra verzoeken worden in de wachtrij geplaatst of genegeerd.
  • Vermijd het overschrijden van frequentielimieten. Wanneer u de frequentielimieten overschrijdt, beperkt de API uw aanvragen, meestal met een HTTP-statuscode 429 Too Many Requests. Throttling heeft meer invloed op de doorvoer van uw toepassing dan snelheidsbeperking dat doet. Gebruik de informatie in antwoordheaders voor frequentielimieten om binnen de limieten te blijven en throttling te voorkomen.

Met behulp van deze technieken kunt u toepassingen bouwen die bestand zijn tegen snelheidsbeperking en kunnen blijven functioneren, zelfs wanneer de API zwaar wordt belast. Test vervolgens of ze dat doen, omdat u tijdens het ontwikkelen zelden tegen een ratelimiet aanloopt.

Hoe u uw rate-limietafhandeling test

Approach Wat u vindt Wat u mist
Wachten op productieomgeving Werkelijke ratelimieten Alles, tot een gebruiker het aanraakt
Mock the API in your tests, or let your coding agent write the mock Of uw code de gesimuleerde headers leest De werkelijke headernamen, indelingen en het resetgedrag van de API, en het retrybeleid van uw SDK. Uw app heeft ook een schakelaar nodig die alleen voor testdoeleinden is bedoeld om de mock te bereiken.
De echte API aanroepen totdat u de limiet bereikt Feitelijk gedrag U kunt niet zomaar naar behoefte de limiet halen, u gebruikt uw werkelijke quotum en sommige limieten worden pas na een uur opnieuw ingesteld
Het echte verkeer van uw app onderscheppen en de limiet simuleren Echte URL's, een limiet, een tijdsvenster dat u kiest en de eigen headers van de API Uw code afzonderlijk. Bewaar daar je unit tests voor.

Probeer het in uw app

Dev Proxy telt de aanvragen van uw app voor de API's die u kiest, voegt frequentielimietheaders toe aan de antwoorden en reageert met 429 wanneer uw app de limiet overschrijdt, terwijl uw app de echte URL's blijft aanroepen. U kiest de limiet en het tijdvenster, zodat u deze in een minuut kunt halen in plaats van in een uur.

Voor GitHub downloadt u de voorinstelling en start u hiermee Dev Proxy:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Gebruik voor Microsoft Graph aanroepen naar OneDrive en SharePoint (/drive, /shares, /sites) de microsoft-graph-rate-limiting voorinstelling. Om Dev Proxy te installeren, raadpleegt u Dev Proxy instellen.

Volgende stap

Testen of mijn toepassing snelheidsbeperking goed verwerkt

  • Laatst bijgewerkt om