更新后端（REST、Spring Boot）的最佳实践是什么？ [关闭]

Question

想象一下，您使用标准 Spring Boot 软件堆栈中的数据库创建了一个简单的单体 REST 后端。您无法控制的任意客户端使用您的 REST 端点。数据库运行在 Docker 容器中，后端运行在单独的 Docker 容器中。

您如何处理对现有功能进行重大更改的更新？当现有数据模型（和数据库架构）发生更改并因此 DTO 或现有 REST 端点的预期调用格式发生更改时，您会怎么做？

在一个正在积极开发的项目中，这似乎是可以预期的，同时它还在生产使用中。但既然你已经推出了一个版本，你必须支持它（至少支持一段时间）。您是否以某种方式对端点进行版本控制？如果是这样，它是如何完成的？您是否保持应用程序的多个实例（每个版本至少一个）运行，并以某种方式希望它们都能正确访问数据库？但是，每个版本仍应使用相同的数据库。

对此是否有任何最佳实践，或者我是否在编造一个不存在的问题？

Answer 1

如果确实有必要更改您应该记录的现有端点，请在您的更改日志中添加一个额外的节点 如果您可以避免使用新端点进行更改，我会建议这样做。

这个问题确实存在，所以最好事先仔细规划你的 API :)

Answer 2

像您描述的更新在生产系统中一直发生。 您可以决定采用以下策略之一：

1.同时更新您的 API 和所有客户端。 根据您拥有的用户数量以及您对其系统的控制程度，您可以与他们一起安排新 API 的发布时间以及他们何时需要开始使用新客户端。在这种情况下，您必须为您的 API 的较新版本提供文档，并可能为您的用户提供一个测试环境以尝试他们的新客户端。

2。将您的重大更改拆分为几个非重大步骤。这通常通过首先发布支持旧格式和新格式的 API 版本来实现。您可以通过使用不同的 URL 或要求不同的参数（例如 version=2）来区分两者。一旦您的所有用户都有机会升级他们的客户端，您就可以放弃对旧版本的支持。

对于这两种策略，您必须宣布更改并与用户沟通，提供有关新 API 的足够通知和足够信息。