WSO2 APIM is een toonaangevend platform voor het bouwen, integreren en publiceren van digitale diensten als beheerde API’s. In het digitale landschap fungeren API’s als brug tussen applicaties, waardoor naadloze gegevensuitwisseling en digitale transformatie mogelijk worden. WSO2 API Manager staat centraal in dit ecosysteem en biedt een uitgebreide reeks functies en mogelijkheden voor het beheer van de volledige lifecycle van API’s.
Een van de belangrijkste features van WSO2 APIM is rate limiting. Rate limiting van API’s is een cruciaal onderdeel van API-beheer waarmee het aantal requests dat binnen een bepaalde periode naar een API kan worden gestuurd, wordt beperkt. Het primaire doel van rate limiting is misbruik te voorkomen, serverresources te beschermen, eerlijk gebruik en monetisering te garanderen en de algehele servicekwaliteit voor API-consumenten te handhaven.
WSO2 ondersteunt verschillende soorten en niveaus van rate limiting. Met custom rate limiting kunnen systeembeheerders dynamische, custom beleidsregels definiëren om de regels voor API-rate limiting af te stemmen op specifieke use cases en vereisten. Het is belangrijk op te merken dat custom rate limiting-beleidsregels globaal op alle tenants worden toegepast. Custom rate limiting-beleidsregels worden gedefinieerd door de Siddhi-querytaal. Daarom kunnen beleidsregels worden geschreven met behulp van Siddhi-queries.
Een custom policy bestaat uit twee hoofdonderdelen: de sleuteltemplate en de Siddhi-query. Er is een reeks toegestane sleutels die als sleuteltemplate kunnen worden gebruikt. Meerdere sleutels kunnen worden gescheiden door een dubbele punt (:), waarbij elke sleutel moet beginnen met het voorvoegsel $. De toegestane sleutels in de sleuteltemplate zijn hieronder weergegeven.
- $resourceKey
- $userId
- $apiContext
- $apiVersion
- $appTenant
- $apiTenant
- $appId
- $clientIp
In de Siddhi-query schrijven we het daadwerkelijke beleid voor. In de query moeten we een throttlesleutel instellen. Als er een mismatch is tussen de throttlesleutel en de sleuteltemplate, wordt de request niet afgeremd. Daarom moet de throttlesleutel in de Siddhi-query overeenkomen met de sleuteltemplate.
Een custom throttling policy maken en testen
Hiervoor gebruik ik de nieuwste versie van WSO2 APIM 4.2 op mijn lokale omgeving. Als je niet weet hoe je dit moet doen, lees dan een van onze blogs waarin wordt uitgelegd hoe je WSO2-producten op Linux/Windows/Mac kunt installeren.
Zodra de WSO2-server actief is, kunnen we de portals openen via de volgende URL’s:
- Publisher portal – https://localhost:9443/pubisher
- Developer portal – https://localhost:9443/devportal
- Admin portal – https://localhost:9443/admin
Voordat je een custom throttling policy kunt maken, moet je eerst een API aanmaken en abonneren. Dit zorgt ervoor dat de API kan worden getest op throttling volgens de custom throttling policy.
Een API aanmaken
In de Publisher-portal maken we een nieuwe API met de vereiste resources. Vervolgens wordt deze API doorgevoerd en gepubliceerd. Daarna kan een custom throttling policy worden gecreëerd om de API te throttlen.
- Ga naar de Publisher portal – https://localhost:9443/pubisher
- • Maak een API aan met de volgende details:
- Ga naar Resources en verwijder de gegenereerde resources. Voeg vervolgens twee GET resources toe voor berichten (posts) en taken (todos), zoals hieronder:
- Ga naar Deployments en implementeer de gemaakte API
- Ga naar Lifecycle and publiceer de geïmplementeerde API
Abonneren op de API
Om een token te genereren en de API-resources aan te roepen, moeten we eerst een applicatie aanmaken in de developer portal en deze abonneren op de gemaakte API.
- Ga naar Developer portal – https://localhost:9443/devportal
- Maak een applicatie aan
- Abonneer op de API
- Genereer een token
API openen
Je kunt elke REST-client of CURL gebruiken om de API te openen. In dit geval gebruik ik Postman om de API-resources aan te roepen met de gegenereerde token om te controleren of de API-resources werken zoals verwacht.
- • Roep de /posts API aan met behulp van de token die je in de vorige stap hebt gegenereerd
- • Roep de /posts API aan met behulp van de token die je in de vorige stap hebt gegenereerd
Beide API’s werken zoals verwacht.
Custom throttling policy maken
Laten we een custom throttling policy maken om het posts-endpoint te throttlen wanneer er meer dan 5 requests binnen een minuut worden gedaan.
- Ga naar Admin portal – https://localhost:9443/admin
- Selecteer Custom Policies en click op Define
- Maak een policy met de volgende details,
Key Template: $resourceKey
Siddhi Query:
FROM
RequestStream
SELECT
userId,
(resourceKey == '/test/v1/v1/posts:GET') AS isEligible,
resourceKey as throttleKey
INSERT INTO
EligibilityStream;
FROM
EligibilityStream [ isEligible == true ] # throttler: timeBatch(1 min)
SELECT
throttleKey,
(count(userId) >= 5) as isThrottled,
expiryTimeStamp
group by
throttleKey
INSERT
ALL EVENTS into ResultStream;
Volgens de policy:
- Heeft KeyTemplate de waarde $resourceKey, wat betekent dat de throttling moet worden gebaseerd op het resource pad.
- In SiddhiQuery:
- resourceKey = /test/v1/v1/posts:GET – throttling moet worden gecontroleerd voor het endpoint /test/v1/v1/posts, wat een GET resource is.
- resourceKey as throttleKey – hier zal de waarde van KeyTemplate dezelfde zijn als de waarde van throttleKey
- timeBatch(1 min) — is de time period van de throttling policy.
- count(userId) >= 5) as isThrottled — is de checker voor het aantal throttling requests (5 requests per gebruikers-ID).
Samengevat betekent de bovenstaande Siddhi-query dat deze policy een gebruiker toestaat om slechts 5 requests per minuut te sturen voor de GET resource /test/v1/v1/posts. Daarna worden de requests gethrottled.
Custom throttling policy testen
Nu moeten we het posts-endpoint meer dan 5 keer aanroepen om te controleren of de request wordt gethrottled. Wanneer we het endpoint meer dan 5 keer aanroepen, krijgen we het volgende bericht met de statuscode 429 (teveel requests):
Zoals hierboven te zien is, werkt de custom throttling zoals verwacht en heeft deze policy geen invloed op het andere endpoint todos. Als het todos-endpoint meer dan 5 keer wordt aangeroepen, zal het blijven werken omdat de custom policy alleen is gemaakt om de posts-resource te throttlen.
Aanvullende Policy – Specifieke API-resource throttlen voor een specifieke gebruiker
Dit is een policy om een specifieke API-resource, de ‘/posts’ resource, te throttlen voor een specifieke gebruiker genaamd ‘saad’ onder de super tenant.
Key Template: $userId:$resourceKey
Siddhi Query:
FROM
RequestStream
SELECT
userId,
(
userId == 'saad@carbon.super'
and resourceKey == '/test/v1/v1/posts:GET'
) AS isEligible,
str: concat('saad@carbon.super', ':', '/test/v1/v1/posts:GET') as throttleKey
INSERT INTO
EligibilityStream;
FROM
EligibilityStream [ isEligible == true ] # throttler: timeBatch(1 min)
SELECT
throttleKey,
(count(throttleKey) >= 5) as isThrottled,
expiryTimeStamp
group by
throttleKey
INSERT
ALL EVENTS into ResultStream;
Zoals te zien is in de bovenstaande query:
- (userId == ‘saad@carbon.super‘ and resourceKey == ‘/test/v1/v1/posts:GET’ ) AS isEligible – hier worden de specifieke gebruikers-ID en het resource pad geselecteerd voor throttling
- str: concat(‘saad@carbon.super’, ‘:’, ‘/test/v1/v1/posts:GET’) as throttleKey – de specifieke gebruikers-ID en het resource pad worden gecombineerd en ingesteld als throttling key, die vervolgens hetzelfde zal zijn als de key template.
- timeBatch(1 min) — is de time period van de throttling policy.
- count(throttleKey) >= 5) as isThrottled – is de checker voor het aantal throttling requests (5 requests voor de throttle key, waarbij 5 requests zijn toegestaan voor de specifieke gebruiker voor de specifieke resource).
Samengevat betekent de bovenstaande Siddhi-query dat deze policy de gebruiker saad@carbon.super toestaat om slechts 5 requests per 1 minuut te sturen voor de GET resource /test/v1/v1/posts en dan zal de request worden gethrottled. De throttling is niet van toepassing op andere resources en ook niet op andere gebruikers voor deze specifieke resource.
Aanvullende Policy – API-aanvragen throttlen voor alle gebruikers behalve de super admin-gebruiker
Dit is een policy om API-aanvragen te throttlen voor alle gebruikers behalve de super admin-gebruiker. Hierdoor worden de aanvragen voor elke gebruiker gethrottled, tenzij de gebruiker een admin is in de super tenant.
Key Template: $userId
Siddhi Query:
FROM
RequestStream
SELECT
userId,
(userId != 'admin@carbon.super') AS isEligible,
userId as throttleKey
INSERT INTO
EligibilityStream;
FROM
EligibilityStream [ isEligible == true ] # throttler: timeBatch(1 min)
SELECT
throttleKey,
(count(userId) >= 5) as isThrottled,
expiryTimeStamp
group by
throttleKey
INSERT
ALL EVENTS into ResultStream;
Zoals te zien is in de bovenstaande query,
- (userId != ‘admin@carbon.super’) AS isEligible – hier worden alle gebruikers behalve de super admin-gebruiker geselecteerd voor throttling.
- userId as throttleKey – userId wordt ingesteld als throttling key, die vervolgens hetzelfde zal zijn als de key template.
- timeBatch(1 min) — is de time period van de throttling policy.
- count(userId) >= 5) as isThrottled – is de checker voor het aantal throttling requests (5 requests voor elke user-ID).
Samengevat betekent de bovenstaande Siddhi-query dat deze policy de super admin-gebruiker (admin@carbon.super) toestaat om een onbeperkt aantal requests te sturen. Alle andere gebruikers kunnen slechts 5 requests per minuut sturen voor alle resources. Daarna worden de requests gethrottled.
Conclusie
Rate limiting is een essentiële functie in elk API management platform. Met behulp van custom rate limiting kun je verschillende voordelen behalen, met name wanneer je specifieke use cases en vereisten heeft die verder gaan dan standaard rate limiting policies. Het biedt nauwkeurige controle over throttling op basis van API-context, versie, resourcepad, gebruikers-ID en meer. Door deze controle kun je aanpassingen doen op basis van veranderende omstandigheden of zakelijke behoeften. Custom rate limiting kan gepersonaliseerde ervaringen voor gebruikers ondersteunen. Je kunt limieten voor de verwerkingsnelheid afstemmen op het gedrag van individuele gebruikers, waardoor je de meest actieve gebruikers een vloeiendere en responsievere ervaring biedt.
Voor sectoren met specifieke compliance-vereisten kan custom rate limiting helpen om ervoor te zorgen dat uw API-gebruik voldoet aan regelgevende normen. Je kunt limieten voor de verwerkingsnelheid implementeren die aansluiten bij compliance-mandaten (compliance mandates). Het is belangrijk op te merken dat hoewel custom rate limiting deze voordelen biedt, het ook zorgvuldige planning, tests en continue monitoring vereist. Het implementeren van complexe logica voor rate limiting moet doordacht gebeuren om onbedoelde serviceonderbrekingen of te restrictieve beleidsregels te voorkomen. Houd daarnaast rekening met de schaalbaarheid van uw oplossing voor custom rate limiting voor growing API usage.
