Java RESTAPI版本控制

我目前正在开发一个基于Java的web应用程序。最近，我们使用Spring创建了一些REST端点。这是因为我们开发了一个混合移动应用程序，通过这些端点与我们的主应用程序集成

问题是，未来我们不太确定如何处理更新。如果我们更新我们的API，例如，我们更改端点方法的方法签名，或者我们更改作为JSON返回的DTO上的属性，那么如果我们的移动用户正在运行过时版本的移动应用程序，那么我们将遇到问题

我们想要实现的是，如果应用程序过时，我们的用户将被迫更新它。我见过很多这样做的移动应用程序。因此，我们考虑为REST API提供一个API版本，然后让移动应用程序检查它使用的版本是否与服务器运行的版本相同，如果不相同，则强制用户进行更新

我们面临的问题是：

我们在任何时候都只有一个版本的服务器在运行。那么我们该如何安排发布时间呢？如果我们发布了新版本的API和移动应用程序，但应用商店尚未公开最新版本，会发生什么情况。然后用户将被迫进行更新，但更新后的应用程序尚不可用

我们如何维护API版本号？在移动应用程序上，我们可以配置它。但是在服务器上，必须维护一个版本号并不好。我这样说的原因是，如果我们对方法签名或DTO等进行更改，并且在发布之前忘记手动更新此版本号，会怎么样？当然有一种更自动的方法可以做到这一点，即根据API的当前定义生成一些唯一的“API密钥”？然后，我们可以使用它来代替API版本号

---

听起来您需要对API进行向后兼容的更新

由于您可以控制在移动端调用API的客户端代码，因此只需编写应用程序代码以忽略JSON响应中出现的新字段。这将大大降低应用程序的脆弱性，并允许您随意扩展对象。充分利用HATEOAS，让您的客户端导航对象中的超链接，而不是将它们硬编码到您的URL结构中

您应该开始为每个服务器版本构建兼容性测试的文化和流程，以便自动验证您的旧API客户端（当然，它将永远存在于从不更新其应用程序的用户的手机上）是否仍能与您计划的服务器更新一起工作。在中，这类似于对API进行小版本升级

---

如果您认为在某个阶段需要对API进行极不兼容的更改，这会破坏您的旧应用程序，那么从一开始就在API客户端中进行“兼容性检查”。启动时，他们应该检查服务器上的简单API以进行基本版本握手。如果服务器响应为“我们无法再支持您的旧客户端代码”，则会显示一条消息，告知用户从应用商店中获取最新版本，以显示您的应用程序错误。但由于这是一种非常糟糕的用户体验，最好从一开始就建立合理的兼容性。

您可以做一些事情

架构师API从一开始就进行版本控制。对于REST API，我看到了两种常见的方法：在所有REST资源端点之前放置URL前缀，如

/v1

，

/v2

，等等，或者使用HTTP

接受

头来协商版本。有一些宗教战争是正确的。这是你的API。做你认为正确的事

从源代码中的API端点代码中抽象出业务逻辑。这样，您就可以有一个v1和v2端点，在较低级别的服务层重用公共代码。这是你一开始就不需要做的事情。您可以等到API的第2版开始分离

根据现有API版本（以及您正在构建的任何新版本）自动测试每个构建，但回归测试是我要说明的关键点

强制应用程序更新，或者至少按应用程序版本跟踪使用情况，可以让您删除/清理任何支持旧版本的代码

我正在做一个类似的项目，为一个新的移动应用程序创建一个新的RESTAPI。我正在按版本划分URL空间，所以

目前，我在接受HTTP请求的代码中构建了我的业务逻辑，因为这种逻辑没有其他用途。然而，当我需要制作一个新版本时，我将重构v1api代码，将任何不特定于v1的内容分离成一个更可重用的模块，然后可以重用

根据您的版本在结构上的不同，您可能需要一些冗余来保持API的分离。例如，您可能需要一个通用的

UserEntity

对象来表示数据库中的用户信息，但是对于带有适配器的单独版本，您可能需要一个UserV1Resource和UserV2Resource对象，或者一些其他设计模式来协调序列化为JSON或XML的不同类型

通过自动化API测试，我可以根据需要自由地进行任何重构，边做边分离，知道一旦我破坏了任何向后兼容性，我的测试就会向我尖叫

---

API目前只被我们的移动应用程序使用的一个好处是，我们只需要担心与支持的应用程序版本的兼容性。如果我们能够确保最终用户定期更新他们的应用程序，我们将能够删除旧版本，这有助于最大限度地减少我们的技术债务。

可能只是重复一个建议，在移动应用程序上有推送通知。事件发生时，请求API版本，若更改，通知用户必须更新Ap