Use the Api as a class instead of as bunch of functions

[MakersF]

Made some changes to the structure of the code. Now you have a class which exposes all the api functions as members. Moreover you can have multiple of this class, which can share any of the key, region, rate limiter and so on.

You can find the changes here. Let me know if you are interested into them (at the moment core doesn't work, as it hasn't been translated to the new pattern)

from cassiopeia.dto.requests import RequestGateway
from cassiopeia.baseriotapi import BaseAPI

rg = RequestGateway('your-api-key', 'NA', print_calls=True)
NA = BaseAPI(rg1)
nb3=NA.get_summoners_by_name(['Nightblue3'])
print(nb3)

rg2 = RequestGateway(rg1.api_key, 'KR', rate_limiter=rg1.rate_limiter)
KR = BaseAPI(rg2)
print(KR.get_summoners_by_name(['cowsep']))

rg2._region = 'NA'
rg2._print_calls = True
print(KR.get_summoners_by_id([nb3['nightblue3'].id]))

Prints

https://na.api.pvp.net/api/lol/na/v1.4/summoner/by-name/Nightblue3?api_key=
{'nightblue3': Summoner({'summonerLevel': 30, 'revisionDate': 1441986280000, 'name': 'Nightblue3', 'profileIconId': 909, 'id': 25850956})}
{'cowsep': Summoner({'summonerLevel': 30, 'revisionDate': 1441972531000, 'name': 'Cowsep', 'profileIconId': 787, 'id': 28730386})}
https://NA.api.pvp.net/api/lol/NA/v1.4/summoner/25850956?api_key=
{'25850956': Summoner({'summonerLevel': 30, 'revisionDate': 1441986280000, 'name': 'Nightblue3', 'profileIconId': 909, 'id': 25850956})}

Examples with summoners, but you can use it for any function in the api

[robrua]

When I initially built Orianna, which Cass is in a lot of ways a new version of, I made the API an object instead of a static resource. In the second version of Ori and in Cass I switched to a static resource based on the following analysis:

1) One important goal of these libraries is to help enforce best practice when accessing the API. As the use of multiple API keys for the same project is forbidden by Riot, this helps enforce that policy

2) It more closely models the "real world" construct that the wrapper represents. This goes along with why API values for Core objects are immutable. The REST API that's being accessed itself is a single static resource, and the data it serves can't be modified.

3) Since the API key should be the same across all API instances in this setup, synchronization of the underlying rate limiters can become cumbersome, especially if the rate limits for several instances are being changed long after creation.

4) The static resource setup allows for "singleton-esque" accessibility of the API anywhere in the application where the rate limit synchronization is handled painlessly.

5) The encapsulation and accessibility control of the methods/data is the part of making this a class which is actually desirable for the wrapper. A module or an abstract class (Java) handles those nicely without bringing along instantiability, inheritence, polymorphism, and the rest of the fixings of classes that don't really serve a purpose in this case.

6) On the flip side, the benefit I see for breaking these out into classes is that you can subdivide your rate limit among multiple tasks and that flipping between calls to different regions is easier.

All things considered, I think the cons of the static resource approach are significantly outweighed. There are alternative solutions to get the same functionality without losing the valuable aspects of the static resources.

[MakersF]

That makes sense! I agree with you.