英文:
What is the best practice for updating backends (REST, Spring Boot)?
问题
假设您创建了一个简单的、单体式的 REST 后端，其中包含一个标准的 Spring Boot 软件栈中的数据库。不受您控制的任意客户端都会使用您的 REST 端点。数据库在 Docker 容器中运行，后端在单独的 Docker 容器中运行。
如何处理对现有功能的更新，以及由于这些更新引入了破坏性变更？当现有的数据模型（以及数据库架构）发生更改，因此现有 REST 端点的数据传输对象（DTO）或期望的调用格式发生变化时，您该怎么办？
在一个正在积极开发并且正在生产使用中的项目中，这似乎是可以预料的。但是，由于您已经发布了一个版本，您必须为其提供支持（至少一段时间）。您是否以某种方式为您的端点进行版本管理？如果是这样，该如何实现？您是否保持多个实例（至少每个版本一个）的应用程序运行，并且以某种方式希望它们都能正确访问数据库？然而，每个版本仍应该使用相同的数据库。
在这方面是否有一些最佳实践，还是我在虚构一个并不存在的问题？
英文:
Imagine you made a simple, monolithic REST backend with a database in the standard Spring Boot software stack. Arbitrary clients which you have no control over consume your REST endpoints. The database runs in a Docker container, the backend runs in a separate Docker container.
How do you handle updates to existing functionality with breaking changes? What do you do, when an existing data model (and database schema) changes and therefore the DTOs or the expected call format of the existing REST endpoints change?
It seems like this is to be expected in a project that is being actively developed while it's in productive use. But since you rolled out a version already, you must support it (at least for a while). Do you version your endpoints in some way? If so, how is it done? Do you keep multiple instances (at least one per version) of the application running and somehow hope they can all access the database properly? However, every version should still use the same database.
Are there any best practices for this or am I making up a problem that does not exist?
答案1
得分: 1
以下是翻译好的部分：
- 更新如您所描述的情况在生产系统中经常发生。您可以决定采用以下策略之一：
1. 同时更新您的API和所有客户端。 根据您的用户数量以及对其系统的控制程度，您可以与他们安排新API的发布时间以及他们需要开始使用新客户端的时间。在这种情况下，非常重要的是为您的API的新版本提供文档，可能还需要为用户提供测试环境，以便他们尝试他们的新客户端。
2. 将您的重大更改分为多个不会破坏现有系统的步骤。 通常可以通过首先发布支持旧格式和新格式的API版本来实现这一点。您可以通过使用不同的URL或要求不同的参数（例如version=2）来区分两者。一旦所有用户都有机会升级其客户端，您可以停止支持旧版本。
使用这两种策略时，非常关键的是宣布更改并与用户沟通，提供足够的通知和有关新API的足够信息。
英文:
Updates like the ones you described happen all the time in production systems.
You may decide to follow one of these strategies:
1. Update your API and all the clients at the same time. Depending on how many users you have and how much control you have on their systems, you may be able to schedule with them when the new API is going to be released and when they'll need to start using a new client. In this case, it's essential that you provide documentation for the newer version of your API and possibly a test environment for your users to try their new clients.
2. Split your breaking change into several non-breaking steps. This is normally achieved by releasing a version of your API that supports the old and the new format first. You could distinguish between the two by having a different URL or requiring a different parameter (such as version=2). Once all your users had the chance of upgrading their clients, you can drop support of your old version.
With both these strategies, it is critical that you announce the change and communicate with your users, providing enough notice and enough information about the new API.
答案2
得分: 0
如果真的有必要更改现有的端点，您应该在变更日志中对其进行记录，可能还要在您的文档中添加一个额外的节点，说明在X.X版本中发生了某些更改。如果可以通过添加新的端点来避免更改，我会建议这样做。
这个问题确实存在，所以在事先仔细规划您的API是很重要的 
英文:
If its really necessary to change an existing endpoint you should document, it in your changelog and maybe also make an extra node in you Documentation that something has changes in Version X.X
If you can avoid a change with a new endpoint, I would suggest this.
This problem does exist, that's why it's good to carefully plan you API beforehand
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论