The purpose of this feature is to allow administrators to selectively control which API calls are throttled, without having to rebuild and deploy a new version every time a throttle is changed.
The core of this feature is a new table listing all of the calls that will be throttled.
CREATE TABLE 'THROTTLED_CALLS'(
'THROTTLE_ID' bigint PRIMARY KEY, --id of the throttle rule
'NORMALIZED_CALL' varchar(256), --normalized api URL, numbers such as {id} replaced with #
'MAX_LOCKS' int NOT NULL, --maximum number of locks per time block
'LOCK_TIMEOUT_SECONDS' int NOT NULL, --duration of each time block, at the beginning of each time block, number of held locks reset
'THROTTLE_EXPIRATION' bigint ,
UNIQUE ('NORMALIZED_CALL')
)
EXPIRATION
This table would contain the api calls that administrators would want to throttle, the maximum number of calls per period, and the period of time after which the max calls would reset.
UserThrottleFilter will have a in-memory cached version of this table. It would periodically check the THROTTLED_CALLS table and update its cached version to reflect the information in the database.
To enforce the Throttle, UserThrottleFilter will use a singleton InMemoryTimeBlockCountingSemaphore, which has already been implemented.
When an request comes in, the request uri will be normalized using a preexisting utility. once normalized, the url is compared to the cached throttled calls to see if it is being throttled. if it is, attempt to get a lock from the semaphore. The key used for the semaphore will be the userID + normalizedThrottledCall.
If we can not get a lock, block the request and return a HTTP 429 error code. otherwise proceed with the other filters.