假设我有两个端点:
- example.com/v1/send
- example.com/v1/read
现在我必须在不失去向后兼容性的情况下更改/send 中的某些内容。所以我正在创建:
- example.com/v2/send
那我该怎么办呢？我是否需要创建与/v1 相同的 example.com/v2/read？让我们想象一下，有很多 Controller 和数百个端点。我会通过更改每个小端点来创建这样的新版本吗？或者我的前端应该像那样使用 API 吗？
- example.com/v1/send
- example.com/v2/read
什么是最佳实践？
最佳答案
随着时间的推移，可能会包含新的端点，可能会删除某些端点，模型可能会更改等。版本控制的目的是:跟踪更改。
您可能会在一段时间内同时支持版本 1 和版本 2，但您几乎不会永远支持这两个版本。在某些时候，您可能会放弃版本 1，而只想保持版本 2 完全正常运行。
因此，将新版本的 API 视为可以独立于先前版本使用的 API。换句话说，一个特定的客户端应该针对 API 的一个版本而不是多个。当然，如果可能的话，最好具有向后兼容性。
适时:您是否考虑过一种媒体类型来处理版本控制，而不是在 URL 中添加版本？
例如，看看 GitHub API .所有请求均由 API 的默认版本处理，但可以使用媒体类型在 Accept header 中定义目标版本(并鼓励客户定义目标版本):
Accept: application/vnd.github.v3+json
关于REST API 版本控制。新版本中包含什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43516966/