Vad är hastighetsbegränsning?

Hastighetsbegränsning är en kontrollmekanism som moln-API:er använder för att reglera antalet begäranden som en användare kan göra under en viss tid. Moln-API-producenter använder hastighetsbegränsning för att säkerställa att flödet av begäranden inte överbelastar tjänsten. Hastighetsbegränsning anger ett tak för hastigheten och volymen för API-anrop. Hastighetsbegränsningar definieras vanligtvis när det gäller begäranden per tidsperiod.

Varför moln-API:er använder hastighetsbegränsning

  • Förhindra överbelastning. Hastighetsbegränsning säkerställer att API-servern förblir stabil och dynamisk genom att förhindra att en enskild användare eller tjänst översvämmar den med för många begäranden.
  • Se till att användningen är rättvis. Hastighetsbegränsning tillämpar principer för rättvis användning genom att säkerställa att ingen enskild användare monopoliserar API-resurserna. Hastighetsbegränsning ger rättvis åtkomst till alla användare.
  • Öka säkerheten. Hastighetsbegränsning hjälper till att minimera distribuerade Denial of Service-attacker och andra missbruk genom att begränsa antalet begäranden från potentiellt skadliga källor.
  • Hantera kostnader. För molntjänstleverantörer hjälper hastighetsbegränsning till att hantera driftskostnader genom att förhindra oförutsägbar eller överdriven användning av resurser.
  • Upprätthålla tjänstens kvalitet. Hastighetsbegränsning säkerställer en konsekvent tjänstkvalitet för alla användare genom att förhindra trafiktoppar.

Så här upplever du hastighetsbegränsning i dina appar

När du skapar appar som integrerar moln-API:er kontrollerar du deras dokumentation för att kontrollera om de stöder hastighetsbegränsning. Om de gör det, får du RateLimit-... eller X-RateLimit-... svarshuvuden med information om hastighetsgränserna. Du kan använda den här informationen i ditt program för att säkerställa att du inte överskrider API:ets hastighetsgränser. Rubriken anger till exempel RateLimit-Remaining antalet begäranden som återstår 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. Vissa API:er skickar bara rubrikerna RateLimit-... 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.

När du överskrider hastighetsgränsen begränsar API:et dina begäranden och returnerar en HTTP-statuskod 429 Too Many Requests . Vissa API:er kan också skicka ett Retry-After huvud för att ange hur länge du ska vänta innan du skickar en annan begäran. Alla API:er följer inte det här mönstret. GitHub kan till exempel svara med 403 i stället för 429.

För att undvika begränsningar och säkerställa att ditt program förblir responsivt, implementera hastighetsbegränsning i ditt program. Beroende på din teknikstack kan olika bibliotek hjälpa dig att hantera hastighetsbegränsning i ditt program. När du har implementerat hastighetsbegränsning i ditt program testar du för att se om det hanterar hastighetsbegränsningen korrekt.

Hur påverkar hastighetsbegränsning din app?

När ett API börjar returnera svar med 429 kraschar en app som inte hanterar dem, visar ett allmänt fel, försöker igen så snabbt att den fortsätter att vara strypt eller tyst släpper data. Du ser sällan något av detta när du utvecklar, eftersom API:et är snabbt, du är den enda användaren och dina testdata är små.

Så här testar du att appen hanterar frekvensbegränsningar

Approach Det här hittar du Vad du saknar
Vänta på bearbetning Verkliga gränser för begärandefrekvens Allt, tills en användare trycker på den
Mocka API:et i dina tester eller låt kodningsagenten skriva mocken Om försöksgrenen körs API:ets verkliga statuskoder, rate limit-headrar och felsvar samt SDK:ns princip för återförsök. Din app behöver också en testinställning för att nå mocken.
Anropa det verkliga API:et tills det hastighetsbegränsar dig 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, din riktiga SDK och återförsöksprincip och API:ets egna headers, med en gräns som du väljer 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 rate limit-header i svaren och returnerar 429 när appen överskrider gränsen, medan appen fortsätter att anropa de faktiska URL:erna. Den visar också när din app anropar API:et igen innan gränsen återställs.

Ladda ned förinställningen för API:et som appen anropar och starta 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 anger en egen gräns för valfritt API finns i Simulera API-svar för hastighetsbegränsning. Information om hur du installerar Dev Proxy finns i Installera Dev Proxy.

Nästa steg

Hantera hastighetsbegränsning

  • Uppdaterades senast