jphackworth
commented
10 years ago Short-term, rate limits per exchange should be understood by the developer.
The main benefit to adding rate-limit awareness, is that you can effectively hammer the API to the maximum permissible rate without going over the limit, but this logic differs per exchange.
Havelock has 600 requests per 10 minutes (from memory). BTC-E uses it's annoying nonce that requires request orchestration if you want more than ~ 4 per second.
Also, if you're using persistent HTTP connections, does the rate limits applied to new HTTP requests or actual GET/POST requests?
Is it possible? Yes. Is it useful? Yes. Is it going to be a pain to implement? I think so. :)
I note that of the APIs wrapped "out of the box", two are rate limited to one query per 15 minutes. While this is absurdly long in my mind, the question should be asked whom is responsible for enforcing this limit and cleaning up from its failures? The Clojure ecosystem wants not for rate limit implementations, so we could totally slap a rate limiter in and enforce that rule. This is probably undesirable as it could hang programs waiting for a 15 minute delayed future to evaluate. However I also kinda feel like having some form of a per-feed atom with the last query time muddies the waters of what is otherwise pure configuration data with state.
Thoughts?