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.
...
When an request comes in, the request URI will be normalized using normalizeMethodSignature() AccessRecordUtils of the Synapse-Warehouse-Records project (copy it over). 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.
...
Administrators could also just directly update the SQL table.
| Method | URI | Body | Parameters | Return | Description | Permission |
|---|---|---|---|---|---|---|
| GET | admin/throttle/ | -- | -- | PaginatedResults<Throttle> | Gets a list of throttle rules | Administrators only |
| POST | admin/throttle/new | Throttle | -- | Id of throttle created | Creates a new throttle rule | Administrators only |
| DELETE | admin/throttle/delete | -- | throttleId | -- | Removes a throttle rule given its id | Administrators only |
| PUT | admin/throttle/update | Throttle | throttleId | -- | Updates an existing entry given its id | Administrators only |
Potential problems
If there are many calls being throttled, the throttle could potentially use up a lot of memory. With N throttled calls and M users, the throttle's map for call counts could have up to M x N entires. Additionally, the map will not remove entries for users that are are no longer making calls so memory will not be freed until an administrator calls clearAllLocks().
...