Help Center/ API Gateway/ Best Practices/ API Policies/ Using Request Throttling 2.0 for Fine-grained Request Throttling/ Introduction
Updated on 2024-11-27 GMT+08:00
View PDF
Share

Introduction

Scenario

If the number of requests initiated from public networks for open APIs on APIG is not limited, the continuous increase in users will deteriorate the backend performance. And what's worse, the website or program will break down due to a large number of requests sent by malicious users. The traditional request throttling policies of APIG throttle requests by API, user, credential, and source IP address.

However, as users and their demands become more diversified, these traditional policies cannot meet the requirements for more refined rate limiting. To resolve this issue, APIG has launched request throttling 2.0, which is a type of plug-in policy. The 2.0 policies enable you to configure more refined throttling, for example, to throttle requests based on a certain request parameter or tenant.

This section describes how to create a request throttling 2.0 policy for rate limiting in different scenarios.

Advantages

  • A request throttling 2.0 policy limits the number of times that an API can be called within a specific time period. Basic, parameter-based, and excluded throttling is supported.
    • Basic throttling: Throttle requests by API, user, credential, or source IP address. This function is similar to a traditional request throttling policy but is incompatible with it.
    • Parameter-based throttling: Throttle requests based on headers, path parameter, method, query strings, or system parameters.
    • Excluded throttling: Throttle requests for specific tenants or credentials.
  • API requests allowed in a time period can be limited by user or credential.
  • Request throttling can be precise to the day, hour, minute, or second.

Restrictions

  • Adding a request throttling 2.0 policy to an API means binding them together. An API can be bound with only one such policy in an environment, but each policy can be bound to multiple APIs. The APIs bound with request throttling 2.0 policies must have been published.
  • For APIs not bound with a request throttling 2.0 policy, the throttling limit is the value of ratelimit_api_limits set on the Parameters page of the gateway.
  • A traditional request throttling policy becomes invalid if a request throttling 2.0 policy is bound to the same API as the traditional one.
  • You can define a maximum of 100 parameter-based throttling rules.
  • The policy content cannot exceed 65,535 characters.
  • If your gateway does not support request throttling 2.0, contact technical support.