小编Ale*_*lex的帖子

关于后端实现的逻辑，我想确定什么可能被认为是 API 的 URI 版本控制的最佳实践。

假设我们有一个带有以下 API 的 Java 应用程序：

http://.../api/v1/user
Request:    
    {
      "first name": "John",
      "last name": "Doe"
    }

一段时间后，我们需要向用户 API 添加另外两个必填字段：

http://.../api/v2/user
Request:    
    {
      "first name": "John",
      "last name": "Doe",
      "age": 20,
      "address": "Some address"
    }

我们为每个版本使用单独的 DTO，一个有 2 个字段，另一个有 4 个字段。

我们只有一个应用程序实体，但我的问题是我们应该如何处理逻辑，作为最佳实践？可以仅在一项服务中处理此问题吗？

如果这两个新字段“年龄”和“地址”不是强制性的，这不会被视为重大变化，但既然是，我认为有几个选择：

• 对于所有用户 API 版本，在业务层仅使用一个管理器/服务（但代码的复杂性在于，只有一个管理器会随着时间的推移而增长很多，并且难以维护）
• 仅对所有用户 API 版本使用一个管理器，并使用一个类作为翻译器，这样我就可以使旧 API 版本与新 API 版本兼容
• 每个用户 API 版本的业务层中的新管理器/服务

如果我只对所有用户 API 版本使用一个管理器并在其中放置一些约束/验证，则 V2 将起作用，但 V1 将抛出异常，因为这些字段不存在。

我知道版本控制是一个很大的话题，但直到现在我才在网上找到具体的答案。我的直觉是，为所有用户 API 版本拥有一个管理器将导致一种与干净代码无关的方法，而且，我认为新版本添加的任何更改都必须尽可能松散耦合，因为将更容易弃用旧方法并及时删除它们。