bunq / sdk_java

Java SDK for bunq API
MIT License
49 stars 23 forks source link

provide non-static API access #93

Open tubbynl opened 6 years ago

tubbynl commented 6 years ago

Currently the java client API is purely based on static access and is based on a SingleTon ApiContext

Static functions don't give a lot of flexibility in usage, i would like the ApiClient to with it's own private final context and providing access to the different API's using that context.

Would you guys consider providing a BunqApiClient having methods-per-concept? for example: https://github.com/stil4m/mollie-api/blob/master/src/main/java/nl/stil4m/mollie/Client.java

current static API can be retained for backwards compatibility via these concepts

It would enable better integration in inversion-of-control / dependency injection (spring beans..) scenario's

OGKevin commented 6 years ago

There was already a request for this, see https://github.com/bunq/sdk_java/issues/34 but after internal discussion we concluded that we won't do this. But that was based on the argument for testing. As it will require a giant refactor.

tubbynl commented 6 years ago

Would you accept a pull request on this?

OGKevin commented 6 years ago

Hmm, if its nicely structured and can be implemented in the other 3 SDK's then i don't see why not. But i think it would be better if you give some pseudo code on what you have in mind.

OGKevin commented 6 years ago

I have a feeling that the generated code must also change for this.

tubbynl commented 6 years ago

the generated code only resides in src/main/java/com/bunq/sdk/model/generated right?

OGKevin commented 6 years ago

yes, which means i would have to make some changes to the generator.

tubbynl commented 6 years ago

Let me first look into it, perhaps that wonโ€™t be required

tubbynl commented 6 years ago

nope; that's required, maybe the code-generation part should also be shared? it will probably be based on a (kind of) wsdl describing the service?

OGKevin commented 6 years ago

WSDL ? ๐Ÿ˜‚ nah.

But no, unfortunately we cant share the code for the generator ๐Ÿ˜‰. So, if you provide some pseudo code so that i can have a look. I'll see if its something we want to do or not. And if so, ill make sure the generated code is compatible.

tubbynl commented 6 years ago

i'll fiddle some in a pull request :)

OGKevin commented 6 years ago

@tubbynl thanks For the PR. The structure makes sense. As this is a giant restructure of all 4 sdk's. Ill plan this for 2.0.0.

tubbynl commented 6 years ago

yes, i guessed that, if you want help testing/reviewing stuff i'm available, for now i'll implement with current state