Refactor a RESTful API Code Base to Support Multiple Versions
A common strategy for managing breaking changes in a RESTful API is to add a new version. This allows clients to continue using the existing REST API and move their applications to the newer API version when they’re ready.
Many discussions and debates exist about how to pass the API versions via URL or Header, etc. However, I couldn’t find many in-depth discussions on how the code base should be structured to manage multiple versions.
This article will discuss how to manage multiple versions in a single application.
Do you need a new version?
The first consideration in refactoring an existing REST API to support multiple versions is whether the new version is needed.
Adding a new version is a big decision. It increases the application's complexity by an order of magnitude. As Martin Fowler mentioned, a new version should only be used as a last resort.
Thus, the #1 rule is to avoid adding a new version.
Breaking Change
Many API changes, like adding a new field in a request or response, don’t have to result in a new version unless they are…
