Wat is SaaS API Rate Limiting?

De SaaS API van een cloudgebaseerde applicatie beperkt het aantal API-aanroepen naar een dienst gedurende een bepaalde periode voor een clientapparaat, gebruiker, IP, sleutel of tenant. De client is geconfigureerd om een specifiek aantal verzoeken te verzenden. Dit type API-beperking heeft gevolgen voor de capaciteit van de service-infrastructuur, aangezien het ook helpt bij de beperking van gebruikerstoegang en ondersteunt bij het beheer van clouduitgaven.

Binnen mechanismen voor snelheidsbeperking is het monitoren van ‘429 Too Many Requests’-berichten een algemene praktijk, wat gebeurt wanneer servers deze naar clients verzenden nadat hun aanvraagdrempel is bereikt. In veel gevallen gebruiken servers de “Retry-After”-header om clients te informeren welke vertraging wordt aanbevolen tussen het opnieuw proberen van verzoeken.

Dit is wat rate limiting specifiek doet:

• Het wordt geassocieerd met het aanpakken van potentiële operationele systeemproblemen die kunnen ontstaan door een groot aantal verzoeken vanuit een onvoorziene bron.
• Het voorkomt activiteiten zoals web scraping of brute-force hacking.
• Het pakt de kosten aan die voortvloeien uit autoscaling of resourcegebruik door downstream systemen.

1. Volg de instructies die worden gegeven in de Retry-After headers.
2. Probeer exponentiële backoff met een willekeurige component.
3. Plaats de verzoeken in de “wachtrij” of verdeel de belasting bij hoge gelijktijdigheid.
4. U kunt aan de clientzijde een token bucket implementeren voor verkeer- en wachtrijbeheer voor workloads die parallellisme vereisen.

Een typische oplossing omvat verschillende lagen: API-gateway, edge-beveiligingsplatform, en servicebeheer- of quotasysteem. De volgende patronen kunnen van toepassing zijn:

• Limieten per sleutel
• Limieten per tenant
• Endpoint-specifieke limieten
• Gelaagde plannen

In gevallen waarin rate limiting bijdraagt aan een grotere hoeveelheid klantcontacten voor ondersteunend personeel, is het raadzaam de basis voor verzoekbeperkingen uit te leggen. De providers moeten worden geadviseerd om:
· Gebruik duidelijke HTTP-statuscodes.
· Toon Retry-After en rate-limit headers.
· De in de documenten gespecificeerde limieten moeten aan de ontwikkelaars worden gecommuniceerd.
· Waar mogelijk, de gebruiksstatistieken van de klant of hun resterende quotum weergeven.

Rate limiting beheert misbruik, kosten en billijkheid, maar de effectiviteit ervan bij het oplossen van problemen in gedistribueerde systemen kan grenzen hebben. De integratie van rate limiting met andere controles verdient aandacht:

• Quota's
• WAF of botbeveiliging
• Authenticatie en idempotentie
• Monitoring