REST API：多个版本，单个应用程序？

Question

我正在使用REST API，因此我将不得不很快引入一些重大更改，因此需要v2。尽管仍并行支持v1，但仍需要几个月的时间，以便让我们的客户有时间在准备好新版本时切换到新的API。我们的API是通过共享云提供的，并且我们所有的客户都共享相同的系统后端，尤其是单个共享数据库。

我找到了很多有关REST API版本控制的文章，但它们更多是从客户端的角度或从高级设计的角度来看的。这并不是我真正关心的问题，我们的API已经在URI中提供了版本控制，因此提供带有/ v2基本路径的服务将不是问题。

但是我问自己，我将如何实际实现它，而我还没有真正找到好的文章。我真的不想分支我的项目的v2，然后将v1和v2分别构建和部署为单独的应用程序，因为那样的话，我将在两个应用程序中进行维护，错误修复，配置更改等，这是双重工作并且通常冗余的危险（即：版本之间可能存在不一致）。同样，v2当然在每个服务中也不相同，因此大多数代码仍将相同。

是否有关于如何在单个应用程序中技术地实现REST API的最佳实践，该应用程序向外部提供多个版本，并且在其中共享了一些代码（即：v2 / someService将在内部重定向到v1 / someService），而实际新服务中编码了差异？也许甚至还有一些框架可以帮助您设计？如果有帮助，该应用程序使用Spring MVC用Java编码。

感谢您提供有关解决此问题的提示或资源。谢谢！

Answer 1

如果我面临你所说的情况，我会首先尝试使我的新版本（v2）向后兼容我的第一个版本（v1）。如果是这种情况，您只需添加功能并更新 API 文档，只保留一个活动代码库。我认为您甚至可以将内容添加到响应负载中，只要返回的数据不会破坏任何人的代码 - 有点像向现有数据库模式添加字段。

如果 v2 不向后兼容 v1，您可以将 v1 移动到另一台服务器，并通知您的用户它将被放置在那里一段规定的有限时间内，以便他们有时间进行必要的代码更改以切换到 v2，但同时也通知他们知道此版本不再更新，如果遇到问题，他们将需要切换到新版本。因此，v2 是代码库的 HEAD 版本，没有其他分支正在积极开发中。

我希望这对您有所帮助并提供您尚未想到的东西。