Supporting multiple versions of models for different REST API versions

Are there any best practices for the implementation of API versioning? I'm interested in the following points:

1. Controller, service - e.g. do we use a different controller class for each version of the API? Does a newer controller class inherit the older controller?
2. Model - if the API versions carry different versions of the same model - how do we handle conversions? E.g. if v1 of the API uses v1 of the model, and v2 of the API uses v2 of the model, and we want to support both (for backward-compatibility) - how do we do the conversions?
3. Are there existing frameworks/libraries can I use for these purposes in Java and JavaScript?

Thanks!

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 eventually converted 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 (frojasg1@hotmail.com)

A link to the library:

github

Shared at my own server

• 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