API Throttling Made Easy
Developers are rate limiting their APIs to improve their application's security and performance. Learn more about API throttling and rate limits in this blog post!
Join the DZone community and get the full member experience.Join For Free
APIs allow you to share your application data with other developers (both internal and external) as well as other apps. As businesses continue to accelerate their API strategies, you as the application manager/owner have to make sure that your application is always secure and high-performing. Well-designed APIs that allow you to throttle API requests are what you need for better security and throughput.
What Is API Throttling?
API throttling allows you to control the way an API is used. Throttling allows you to set permissions as to whether certain API calls are valid or not. Throttles indicate a temporary state and are used to control the data that clients can access through an API. When a throttle is triggered, you can disconnect a user or just reduce the response rate. You can define a throttle at the application, API, or user level.
As a developer, you have control over what applications and which users can use your APIs. Just like permissions, a combination of multiple throttles may be used in a single request. You can even have multiple levels of throttling based on the user. For example, you can restrict sensitive information from external developers, while giving access to the same for internal developers.
Why Do You Need Throttling?
- APIs are a gateway to your backend resources and throttling offers you an extra layer of protection for those resources.
- You can deliver consistent applications by making sure that a single client is not suffocating your applications. Enhanced performance will drastically improve the end-user experience.
- You can control user authentication and access by rate limiting APIs at various levels - resource, API, or application.
- You can design a robust API that can be leveraged by multiple groups based on their access level. Simplified API monitoring and maintenance can help reduce your costs.
What Are the Types of Throttling?
Enterprises custom throttle their APIs based on the needs of their organization such as monetization, authentication, security, governance, performance, availability, etc. Here are some general throttling strategies adopted by the industry today to help you decide what your API needs:
- Rate-Limit Throttling: This is a simple throttle that enables the requests to pass through until a limit is reached for a time interval. A throttle may be incremented by a count of requests, size of a payload, or it can be based on content; for example, a throttle can be based on order totals. This is also known as the API burst limit or the API peak limit.
- IP-Level Throttling: You can make your API accessible only to a certain list of whitelisted IP addresses. You can also limit the number of requests sent by a certain client IP.
- Scope Limit Throttling: Based on the classification of a user, you can restrict access to specific parts of the API - certain methods, functions, or procedures. Implementing scope limits can help you leverage the same API across different departments in the organization.
- Concurrent Connections Limit: Sometimes your application cannot respond to more than a certain number of connections. In such cases, you need to limit the number of connections from a user/account to make sure that other users don't face a DoS (Denial of Service) error. This kind of throttling also helps secure your application against malicious cyberattacks.
- Resource-Level Throttling (also referred to as Hard Throttling): If a certain query returns a large result set, you can throttle the request so that your SQL engine limits the number of rows returned by using conditions attributes like TOP, SKIP, SQL_ATTR_MAX_ROWS, etc.
- Tiers of Throttling: Throttling can be applied at multiple levels in your organization:
- API-level throttling.
- Application-level throttling.
- User-level throttling.
- Account-level throttling.
Published at DZone with permission of Nishanth Kadiyala, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.