Support for Rate Limiting

[ObjectIsAdvantag]

goal would be to help do some QA by simulating 429 from the webex cloud platform
https://developer.webex.com/docs/api/basics#rate-limiting

[ObjectIsAdvantag]

I am thinking about several options to add the feature:

• it could be manual: the user of the emulator turns rate limiting on/off manually
• it could be dynamic: the emulator supports rate limiting policies, which are dynamically checked by the product

Because of the use cases of bots, I think we need the dynamic option.

[ObjectIsAdvantag]

For rate limiting policies, we should create policies that serve the purpose of the developer,
so QA use cases such as:

• A. turn all operations to 429 over periods of M minutes (periodic timer)
• A.1. turn GET /messages to 429 over periods of M minutes (periodic timer)
• B. turn all operations to 429 after R requests over M minutes (requests timed quotas)
• B.1 turn GET /messages to 429 after R requests over M minutes (requests timed quotas)

[ObjectIsAdvantag]

In terms of implementation, it would help to provide native support from the emulator in order to provide 429 headers / responses that would mimic webex behavior.

for example: for the webex emulator hosted at Heroku, alternate option would be to use Heroku's core rate limiting feature, which is described here: check for rate_limit: https://devcenter.heroku.com/articles/platform-api-reference
and also here: https://blog.heroku.com/seven-ways-to-fortify-your-application
though the answer is an error with a JSON payload, no Retry headers as does webex

{
  "id":       "rate_limit",
  "message":  "Your account reached the API rate limit\nPlease wait a few minutes before making new requests",
  "url":      "https://devcenter.heroku.com/articles/platform-api-reference#rate-limits"
}

[jpjpjp]

I think we could also take a page from the https://github.com/jpjpjp/bot-test-framework-example project.

This project introduces a middleware which allows the caller of the API to include headers that instruct the emulator to do certain things. In the bot test frameworkthe middleware handles headers that instruct it to wait for subsequent bot responses to various API responses and events in order to provide regression testing for bot logic.

This same approach could be used to have the caller of the emulator instruct it to provide certain responses. As an example it could support requests that include headers like:

• X-Response-Status-Code
• X-Response-HeaderX
• X-Response-JSON-Body-String

So if for example, I want to ensure that my app properly supports rate limiting retry logic I could make a request that includes:

• X-Response-Status-Code: 429
• X-Response-Header1: "Retry-After:10"
• X-Response-JSON-Body-String: '{"message": "The user has sent too many requests in a given amount of time. Please refer to the Retry-After response header to wait before making a new request.", "errors": [{"description": "The user has sent too many requests in a given amount of time. Please refer to the Retry-After response header to wait before making a new request."}],"trackingId": "ROUTER_5F3314D5-F6C6-01BB-50B7-AC12D93D50B7"}'

The middleware could intercept the default emulator response and replace the specified elements as requests.

This approach would be flexible and allow developers to test a variety of "hard to create" error conditions. The downside of this approach is that it requires the user of the emulator to correctly set the headers to values that match with what the Webex platform would return in the real world. Ideally the maintaintrs of the middleware could develop a nice collection of samples that developers could start from.