c# - How to design an API Wrapper/a Class Library -

i'm working on api wrapper uses json api need api key for.

now api has multiple functions, of need said key for.

i'm asking myself now, how should deisgn in best way? should create 1 class user enters api key , has access 'sub classes' or should make classes public , ones need api key, should enter it? problem need enter multiple times create instances of every class want use.

i thought making public class public instances of internal classes (that need api key) , when creating instance of said class need enter key once , have access classes these public instances. thing doesnt work due internal classes; should make them public , give user ability create classes seperate or use public class?

hope not confusing.

thanks!

edit:

more information:

the api works using requests parameters in url, api key included. reponse deserialized different classes.

not classes require api key (as not requests manage them etc.). main question more like, should make 1 main class user has access functions of api (using instances of classes) or different classes , user can pick , choose 1 needs has enter key whenever wants 'grab' data.

i think see.

so believe first proposal create 1 class each api endpoint , class encapsulate behavior necessary make particular request , deserialize response. avoid approach , issue api key 1 example of why.

here have cross cutting concern (authentication/authorization) , approach require consumer of api wrapper spread logic on application (everywhere instantiate 1 of these objects). if key changes going have go through application , replace old keys new keys. simple find , replace work still ugly. maybe anticipated key changing instead of hardcoding key everywhere instantiated object used key factory instead generate key. have change key in 1 place, in key factory. or maybe key factory reads key config file every time generates key , hot swappable don't have recompile code. pretty clever of them why put consumer of api wrapper through this.

another cross cutting concern less obvious sending request , receiving response. less obvious because will, presumably, not require user pass in constructor but, instead, hardecode instantiation of httpclient in class itself, maybe in constructor. perhaps have anticipated , created abstract base class instantiates httpclient , of other classes inherit class isolated , not spread on api wrapper.

but have issue. lifetime of each of these objects , more importantly lifetime of httpclient each object encapsulates? thing httpclient is designed long lived , handle multiple requests. preferably should have one httpclient per api persists entire duration of application.

i suspect bump against other cross cutting concerns , find similar dilemma on hands.

i recommend create 1 api wrapper class expected instantiated once , used lifetime of application. class encapsulate 1 httpclient. consumer of api wrapper pass dependencies, api key, class when instantiated via constructor. each api end point api wrapper expose 1 (or more) asynchronous methods return typed task task<data> or task<news>, instance.