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.
...
| Code Block | ||
|---|---|---|
| ||
CREATE TABLE 'THROTTLE`THROTTLE_RULES'RULES`( 'THROTTLE_ID' `THROTTLE_ID` int(20) PRIMARY KEY, --id#id of the throttle rule 'NORMALIZED_URI' `NORMALIZED_URI` varchar(256) NOT NULL, --normalized#normalized api URL, numbers such as {id} replaced with # 'MAX_CALLS' `MAX_CALLS` int(20) NOT NULL, --maximum#maximum number of calls per user per URI per bin 'CALL `CALL_PERIOD_IN_SECONDS'SECONDS` int(20) NOT NULL, --bin#bin of time in which a user is allowed to make MAX_CALLS API calls. 'TIMESTAMP' `TIMESTAMP` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, --Timestamp#Timestamp of when the row was changed. used as an etag for migration PRIMARY KEY(`THROTTLE_ID`), UNIQUE ('NORMALIZED`NORMALIZED_CALL'URI`) ); |
The NORMALIZED_URI column must be unique since having 2 different throttling rules for the same API call would not make sense(maybe consider making this primary key instead of using numeric id?).
...
For the service specific throttle, the request URI will be normalized using normalizeMethodSignature() in AccessRecordUtils of the Synapse-Warehouse-Records project (move/refactor?).
...