Hantera hastighetsbegränsning

Hastighetsbegränsning är en vanlig teknik som används av API-leverantörer för att hantera antalet begäranden som kan göras till deras tjänst under en viss tidsperiod. API-leverantörer använder hastighetsbegränsning för att säkerställa att deras tjänst förblir tillgänglig och responsiv för alla användare och för att förhindra missbruk eller överanvändning av tjänsten.

När du använder moln-API:er i ditt program bör du förstå deras hastighetsgränser. Följande tekniker kan hjälpa dig att hantera hastighetsbegränsning i dina program:

  • Förstå hastighetsbegränsningar. Kontrollera dokumentationen för api:et som du använder för att förstå hastighetsbegränsningarna. Hastighetsbegränsningar kan bero på API-providern eller den tjänstplan som du använder. Vissa API:er kan till exempel ha olika prisgränser för kostnadsfria och betalda planer.
  • Använd information om hastighetsbegränsning. API:er som använder frekvensgränser kommunicerar vanligtvis de aktuella gränserna i svarshuvudena. Till exempel RateLimit-Remaining anger rubriken antalet begäranden som finns kvar i det aktuella fönstret. Om du får ett svar med det här huvudet inställt på 0 vet du att du har nått hastighetsgränsen och bör vänta till nästa fönster innan du skickar en annan begäran. Rubriken RateLimit-Reset anger den tid då hastighetsgränsen återställs. Rubriknamn och format skiljer sig åt per API: GitHub till exempel använder x-ratelimit-remaining och x-ratelimit-reset i UTC-epoksekunder. Vissa API:er skickar bara headers när du har nått ett tröskelvärde. Ett exempel är när du har 10% av de begäranden som återstår.
  • Optimera API-användning. Vissa tjänster tilldelar olika kostnader till olika begäranden baserat på deras komplexitet. Vissa API:er kan till exempel debitera mer för begäranden som returnerar mer data. Om du vill minska kostnaden för ditt program optimerar du API-användningen genom att bara hämta de data som du behöver. Använd batchbegäranden om API:et stöder dem. De hjälper dig att minska antalet resurser som krävs för att bearbeta svaret och hålla dig inom hastighetsgränserna.
  • Implementera en lokal hastighetsbegränsning. Implementera en hastighetsbegränsning i själva programmet för att begränsa antalet begäranden som kan göras till API:et under en viss tidsperiod. Du kan göra det genom att använda tekniker som token bucket- eller läckande bucket-algoritmer, vilket möjliggör för applikationen att göra många förfrågningar per tidsperiod. Alla fler begäranden placeras i kö eller ignoreras.
  • Undvik att överskrida hastighetsgränserna. När du överskrider anropsgränserna begränsar API:et dina begäranden, vanligtvis med en HTTP-statuskod 429 Too Many Requests. Throttling påverkar programmets genomströmning mer än vad hastighetsbegränsningen gör. Använd informationen i svarshuvuden för begränsning av begärandefrekvens för att hålla dig inom gränserna och undvika strypning.

Med hjälp av dessa tekniker kan du skapa program som är motståndskraftiga mot hastighetsbegränsning och kan fortsätta att fungera även när API:et är hårt belastat. Testa sedan att de gör det, eftersom du sällan når en gräns för begäranden när du utvecklar.

Så testar du din hantering av begärandefrekvensbegränsning

Approach Det här hittar du Vad du saknar
Vänta tills produktionen är klar Verkliga gränser för begärandefrekvens Allt, tills en användare träffar den
Mocka API:et i dina tester eller låt kodningsagenten skriva mocken Om koden läser headers som du har mockat API:ets faktiska headernamn, format och återställningsbeteende samt SDK:ns återförsöksprincip. Din app behöver också en testflagga för att nå mocken.
Anropa det verkliga API:et tills du når gränsen Faktiskt beteende Du kan inte nå gränsen vid behov, du använder din verkliga kvot och vissa gränser återställs endast efter en timme
Fånga upp appens verkliga trafik och simulera begränsningen Verkliga URL:er, en gräns och ett tidsfönster som du väljer samt API:ets egna huvuden Din kod i isolering. Spara det till enhetstesterna.

Prova det i din app

Dev Proxy räknar appens begäranden till de API:er du väljer, lägger till hastighetsbegränsningshuvuden i svaren och svarar med 429 när appen överskrider gränsen, medan appen fortsätter att anropa de verkliga URL:erna. Du väljer gränsen och tidsfönstret, så att du kan nå den på en minut i stället för en timme.

För GitHub laddar du ned förinställningen och startar Dev Proxy med den:

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

Använd förinställningen /sites för Microsoft Graph-anrop till OneDrive och SharePoint (microsoft-graph-rate-limiting, /drive, /shares). Information om hur du installerar Dev Proxy finns i Installera Dev Proxy.

Nästa steg