provide non-static API access

[tubbynl]

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]

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]

Would you accept a pull request on this?

[OGKevin]

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]

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

[tubbynl]

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

[OGKevin]

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

[tubbynl]

Let me first look into it, perhaps that won’t be required

[tubbynl]

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]

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]

i'll fiddle some in a pull request :)

[OGKevin]

@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]

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