Backward Compatibility in the RESTful API

Question

I am currently developing a RESTful API implemented using ASP.NET web API.
One very important point is backward compatibility.
I would like the actual API code to not contain any thoughts on backward compatibility in order to provide a clean and modern design.
I was thinking about solving this, having a layer of version translators.
Each of these translators knows how to convert requests and responses from one particular version (vPrevious) to those that have another specific version (vCurrent).
These translators can be easily folded to provide backward compatibility with an arbitrary number of older versions.
Each of these translators will be responsible for all sorts of things, such as setting default values ​​for new properties or even performing an array of various operations.

I was thinking of implementing a DelegatingHandler that checks the version number of the API that the client wants to use, and based on this, knows which translators to use.
However, I do not understand how I will really implement this. As I can see, each translator should actually have a full-featured ASP.NET Web API, as well as a routing table and controllers. That would be acceptable, but how does this translator controller route the data to the next chain?

Answer 1

I think the cleanest way is to support every version that is needed to support, work. This means that each version has its own branch in your VCS and is focused on servicing customers who use this particular version. The code is clean and focused on one version. If you need to work with common components / databases, etc., I think that you should implement this level further in your architecture, and not in the REST API level. This level of version control should be the first behind the REST API.

If this does not really work, I would probably design it so that the latest API is the only API that works against your real backend. Other versions simply invoke other versions using a regular HTTP request ... older versions are REST clients of the new APIs. It is not very fast, but the design is very clean and it is easy to understand where the version code is going. If you have many clients that work against older versions of the API, this may lead to a too slow solution, and you need to find more efficient ways to execute it, but then we will almost return to the first solution.