We’re here again to talk about APIs, and today’s subject is policies.
That’s a very important subject, because, usually, an API is developed to work as a public communication interface.
Like most things in life, if you make something totally free and establish no rules for it, you’ll have problems.
In this way, if you know much about APIs policies, everything will be under control.
Besides that, there are many benefits in using this technique, as more security and scalability. Using it means “forcing” your API consumer to do it more consciously.
Now let’s see how that works:
Throttling and Rate limiting
These are the most used terms when talking about policies in APIs, and in many cases, throttling and rate limit can mean the same thing, but, technically, they don’t.
In theory, rate limit and throttling are complementary to each other but don’t do the same things.
Rate-limiting is setting a limit for requests accepted by the API in a determined time range. For instance, 100 requests for each 1 hour.
Throttling is setting an exceeded requests queue that will be processed later on. That is, throttling is the delay amount for processing that request when the client exceeds the rate limit parameters. For instance: 2 retries with a 1-minute delay for each one.
Both can be configured in a granular way, for instance: per client, per resource, per API, etc.
In sum, rate limiting protects your API from high requests consumption, as throttling prepares your API to access peaks.
Using our example API:
Imagine that I want to set my rate-limit to 5 requests per minute, and a 1-retry with a 1-minute delay throttling.
If the client makes a request at 8:00 pm, our API should behave like the following:
Note that when we reach our seventh request, our API won’t allow any more requests, and will return HTTP Status 429 — Too Many Requests.
If you haven’t read my article about HTTP status codes, check it out here.
This term is widely used when the APIs have a commercial approach, with a bigger quota renewing period.
For instance, a client’s API quota is 5 thousand requests per month.
Note that now I’m talking about a monthly period, not about minutes, hours or other shorter periods.
That’s mainly used when clients are charged for consuming the API. When clients need to check their usage, a monthly view is easier to view and understand, almost like your cellphone view.
It’s worth highlighting that API quotas can be combined with rate-limiting, because you can combine a monthly limitation of 5.000 via API quota with a rate-limiting of 100 requests per minute. Note that both don’t exactly add up because the client won’t always be making 100 requests per minute, so, taking a closer look, those two techniques don’t have a direct dependency.
API Burst (Plus)
If your infrastructure is idle and you want to provide better processing performance and more requests to a certain client, you can use API Burst technique.
For instance, your rate-limit setting is 10 per minute, but a certain client sends 20 requests at once. You can process and return all of these requests with high performance because your API has idle capacity on the server.
If you want to know more about this algorithm, I strongly recommend this link.
That’s it, hackers. Did you understand the policies thing?
Remember that each programming language may have different approaches to implementing these techniques, so my recommendation is to use existing frameworks or, obviously, using an API Management platform.
And that’s the end of another article. Thank you very much and I’ll wait for you in the next one.