Open tubbynl opened 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.
Would you accept a pull request on this?
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.
I have a feeling that the generated code must also change for this.
the generated code only resides in src/main/java/com/bunq/sdk/model/generated
right?
yes, which means i would have to make some changes to the generator.
Let me first look into it, perhaps that wonโt be required
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?
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.
i'll fiddle some in a pull request :)
@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.
yes, i guessed that, if you want help testing/reviewing stuff i'm available, for now i'll implement with current state
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