Wat is snelheidsbeperking?

Snelheidsbeperking is een controlemechanisme dat cloud-API's gebruiken om het aantal aanvragen te reguleren dat een gebruiker in een specifieke tijd kan indienen. Cloud-API-producenten gebruiken snelheidsbeperking om ervoor te zorgen dat de stroom van aanvragen de service niet overweldigt. Snelheidsbeperking stelt een limiet in voor de snelheid en het volume van API-aanroepen. Tarieflimieten worden doorgaans gedefinieerd in aantal verzoeken per tijdsperiode.

Waarom cloud-API's frequentiebeperking gebruiken

  • Overbelasting voorkomen. Snelheidsbeperking zorgt ervoor dat de API-server stabiel en responsief blijft door te voorkomen dat één gebruiker of service deze overspoelt met te veel aanvragen.
  • Zorg voor eerlijk gebruik. Snelheidsbeperking dwingt eerlijk gebruiksbeleid af door ervoor te zorgen dat geen enkele gebruiker de API-resources in beslag maakt. Snelheidsbeperking zorgt voor billijke toegang tot alle gebruikers.
  • Verhoog de beveiliging. Snelheidsbeperking helpt bij het beperken van gedistribueerde Denial of Service-aanvallen en ander beledigend gedrag door het aantal aanvragen van mogelijk schadelijke bronnen te beperken.
  • Kosten beheren. Voor cloudserviceproviders helpt snelheidsbeperking bij het beheren van operationele kosten door onvoorspelbare of overmatige gebruik van resources te voorkomen.
  • De kwaliteit van de service behouden. Snelheidsbeperking zorgt voor een consistente kwaliteit van de service voor alle gebruikers door verkeerspieken te voorkomen.

Hoe u snelheidsbeperking in uw apps ervaart

Wanneer u apps bouwt die cloud-API's integreren, controleert u de bijbehorende documentatie om te controleren of deze ondersteuning bieden voor frequentiebeperking. Als dat zo is, ontvangt u RateLimit-... of X-RateLimit-... antwoordkoppen met informatie over de frequentielimieten. U kunt deze informatie in uw toepassing gebruiken om ervoor te zorgen dat u de frequentielimieten van de API niet overschrijdt. De RateLimit-Remaining header geeft bijvoorbeeld het aantal aanvragen aan dat in het huidige venster resteren. 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. Sommige API's verzenden de RateLimit-... headers pas nadat u een drempelwaarde hebt bereikt. Een voorbeeld is wanneer u 10% van de aanvragen over hebt.

Wanneer u de frequentielimiet overschrijdt, beperkt de API uw aanvragen en retourneert een HTTP-statuscode 429 Too Many Requests . Sommige API's kunnen ook een Retry-After header verzenden om aan te geven hoe lang u moet wachten voordat u een andere aanvraag verzendt. Niet elke API volgt dit patroon. GitHub kan bijvoorbeeld antwoorden met 403 in plaats van 429.

Implementeer snelheidsbeperking in uw toepassing om beperking te voorkomen en ervoor te zorgen dat uw toepassing responsief blijft. Afhankelijk van uw technologiestack kunnen verschillende bibliotheken u helpen bij het afhandelen van snelheidsbeperking in uw toepassing. Nadat u snelheidsbeperking in uw toepassing hebt geïmplementeerd, test u of deze snelheidsbeperking correct verwerkt.

Hoe is snelheidsbeperking van invloed op uw app?

Wanneer een API antwoorden retourneert 429, crasht een app die deze niet verwerkt, geeft deze een algemene fout weer, doet deze zo snel nieuwe pogingen dat deze onder throttling blijft, of verliest deze stilzwijgend gegevens. U ziet dit zelden tijdens het ontwikkelen, omdat de API snel is, u de enige gebruiker bent en uw testgegevens klein zijn.

Testen of uw app aanvraaglimieten verwerkt

Approach Wat u vindt Wat u mist
Wacht op productie Werkelijke ratelimieten Alles, totdat een gebruiker erop klikt
Mock de API in je tests, of laat je codeeragent de mock schrijven Of uw retry-vertakking wordt uitgevoerd De werkelijke statuscodes, frequentielimietheaders en foutteksten van uw API, en het beleid voor nieuwe pogingen van uw SDK. Uw app heeft ook een testswitch nodig om de mock te bereiken.
De echte API aanroepen totdat deze u een rate-limiet oplegt Werkelijk 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, uw echte SDK en beleid voor opnieuw proberen, en de eigen headers van de API, met een limiet die u kiest Uw code op zichzelf. Bewaar uw unittests daarvoor.

Probeer het in uw app

Dev Proxy telt de aanvragen van uw app naar de API's die u kiest, voegt headers voor frequentielimieten toe aan de antwoorden en wordt 429 geretourneerd wanneer uw app de limiet overschrijdt, terwijl uw app de echte URL's blijft aanroepen. Er wordt ook aangegeven wanneer uw app de API opnieuw aanroept voordat de limiet opnieuw wordt ingesteld.

Download de voorinstelling voor de API die uw app aanroept en start er dev proxy mee:

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. Als u uw eigen limiet voor elke API wilt instellen, raadpleegt u API-antwoorden voor snelheidslimiet simuleren. Zie Dev Proxy instellen om Dev Proxy te installeren.

Volgende stappen 

Snelheidsbeperking afhandelen

  • Laatst bijgewerkt om