Api key specific to RateLimiter

[linahanner]

As has been mentioned in issue #10 the rate limitation is specific to each key. Right now the key being used is determined by the key within the ApiConfiguration and the rates are counted regardless of which key is being used.

This prevents the user of the library from using multiple api keys for the same ApiReader and would need to create multiple instances of the ApiReader for each key and write their own logic in case a key has reached its limit.

A suggestion is to store each api key inside of the rate limiters, instead of inside the ApiConfiguration. That way we can easily apply the logic of the rate limiters for each key and allow for things, such as, being able to have multiple api keys and once one key has reached its limits it will automatically go to the next key in the list.

This would include logic such as...

• Being able to add and remove api keys from an ApiReader (which automatically creates a default rate limiter or a specified rate limiter)
• Only being able to have one rate limiter for each api key
• Only update the rate counter of the rate limiter related to the api key used for the specific request

Does this sound like a good idea, @avivbiton?

[avivbiton]

The intened behind the TimeRateLimiter is that it is useful when you want to set a custom limit to your key rather then the amout set by Blizzard. This is useful when you have multiple clients running with the same key and don't want one client to drain all the requests leaving all the other clients empty.
Currently on mobile i will go a bit more in depth when i get home

[avivbiton]

IRateLimiter Interface is there so we can easily add new types of limiters, as well allow easy creation of custom rate limiter outside the library.
TimeRateLimiter is just the basic one I made and wanted to allow other contributors to work on more therefore I didn't expend much on that.
By that, it means you can easily create a new type of IRateLimiter that can handle multiple keys

I do like the idea of allowing multiple keys to be added to the ApiReader (I feel like it will fit better there) and then allow some options on how they rotate / used.
Also, I kinda want to create some sort of sketch on about the different abstraction level of the library and maybe make some changes, I will do that soon and open an issue about it .

[avivbiton]

On hold until the migration to the new portal is done