问题描述
想象一下，您使用标准Spring Boot软件堆栈中的数据库创建了一个简单的整体式REST后端。您无法控制的任意客户端都会使用您的REST端点。数据库运行在Docker容器中，后端运行在单独的Docker容器中。
您如何处理具有重大更改的现有功能的更新？当现有数据模型（和数据库架构）发生更改，因此现有REST端点的DTO或预期的调用格式发生更改时，您会怎么做？
在生产性使用中正在积极开发的项目中，这似乎是可以预期的。但是，由于您已经推出了一个版本，因此您必须（至少一段时间）支持它。您是否以某种方式对端点进行版本控制？如果是这样，怎么做？您是否正在运行该应用程序的多个实例（每个版本至少一个实例），并以某种方式希望它们都能正常访问数据库？但是，每个版本仍应使用相同的数据库。
解决方法
像您描述的更新始终在生产系统中发生。 您可以决定采用以下策略之一：
1。同时更新您的API和所有客户端。根据您拥有多少用户以及对他们的系统拥有多少控制权，您也许可以与他们计划何时发布新的API以及何时需要开始使用新客户端。在这种情况下，必须为API的较新版本提供文档，并可能为用户提供一个测试环境，以供他们尝试使用新的客户端。
2。将重大更改分为几个不间断的步骤。通常，这是通过发布API的版本来实现的，该版本首先支持旧格式和新格式。您可以通过具有不同的URL或需要不同的参数（例如version = 2）来区分两者。一旦所有用户都有机会升级其客户端，就可以放弃对旧版本的支持。
使用这两种策略，至关重要的是，您要宣布更改并与用户进行交流，并提供有关新API的足够通知和足够信息。
,如果确实有必要更改现有端点，则应在更改日志中进行记录，并在您的文档中添加一个额外的节点，以确保X.X版中的某些内容发生了更改 如果您可以避免使用新的端点进行更改，则建议这样做。
这个问题确实存在，这就是为什么事先仔细计划API的原因：）