I will try to partly speak about the topic.
We have faced a similar question, when using different versions of an Open Api interface.
The main question was:
Does having a common business logic for the different api versions make sense?
And, if the business logics of the different versions are very similar, in order not to duplicate code, we are considering the option of using a library that generates code (super-models, which are a super-set of all model versions).
This is only possible if all model pojos are compatible in the different versions.
If so, the idea, is to translate the particular model request into a super-model request, which would be the suitable pojo for running your business logic.
And then, when you have a super-model answer, you will have to translate it into the particular model answer, before being converted eventually into json by Jersey (or whatever library you use)
I want to share with you the library I programmed to try to solve the problem (it is at a very early stage, but its unit tests work).
If you try it and have problems, you can contact me at ([email protected])
A link to the library:
Shared code includes the code generator (if pojos are compatible in all different versions, you can generate a super-pojos model) (I think that it can only work with java-8 currently, which might be a problem).
The common or almost common business logic has to work with those super-pojos, so before invoking it, you have to use a mapper that translates from a particular pojo, to the super-pojo. (A default implementation of that mapper using reflection is also included in the library)
The business logic produces the super-pojo answer
The super-pojo answer, has to be translated into a pojo answer (with a mapper with a default implementation included in the library)
And finally you can issue the answer to the network