新的 API 版本是否也应该支持旧版本的所有 API？【设计题】答案

【问题标题】：Should new API version supports all apis of older versions also ? [Design question]新的 API 版本是否也应该支持旧版本的所有 API？【设计题】
【发布时间】：2018-11-17 19:13:14
【问题描述】：

我在base/api/v1/end-point1、base/api/v1/end-point2、base/api/v1/end-point3 等处公开了一组api。这些基本上是v1 api。

现在我们将继续公开v2 api。在这个新的 api 版本中，我们将添加一些新的 api，重构一些现有的 (v1) api，并且一些 api 将保持不变。

所以我的问题是我是否也应该在 v2 中公开所有未更改的 v1 api？

示例：

API V1：

api/v1/users - 保持不变

api/v1/feature1 - 会改变

其他端点...

API V2：

api/v2/feature1 - 重构功能

api/v2/feature2 - 新增

api/v2/users - 我也应该公开这个吗？

我认为：

我不应该：因为它是一样的

我应该：因为如果它没有公开，那么客户端将需要为不同的资源使用不同的 api 版本（端点）。

你在做什么？你有什么看法？任何参考任何最佳实践资源将不胜感激。

如果这个问题不适合这个平台，请告诉我。我很乐意在适当的地方问这个问题。

【问题讨论】：

关于 REST 不需要对 API 进行版本控制，而是您交换的媒体类型，因为它们定义了交换的有效负载的语法和语义。 REST 不是关于调用方法，而是关于资源状态。如果您查看 HTML，即它被定义为向后兼容。因此，任何了解 HTML 5 的客户也确实了解以前的版本。不过，对于您的 RPC 式视图，您是否想要向后兼容主要是您的选择
感谢您的评论@RomanVottner

标签： rest django-rest-framework api-design

【解决方案1】：

是的。

每个版本都应该独立于其他版本。基本原理是，一旦一个 API 版本向公众发布，它的行为将保持不变，直到它被弃用。这确保了所提供的 API 是稳定的，并且不会因不同的响应而中断。同样从使用 API 的最终开发人员的角度来看，它是干净的，不会混淆记住多个版本。

我们通常有多个版本控制，如 SEMVER docs 中所述

给定版本号 MAJOR.MINOR.PATCH，增加：

进行不兼容的 API 更改时的主要版本

以向后兼容的方式添加功能时的次要版本，并且

当您进行向后兼容的错误修复时的 PATCH 版本。

【讨论】：