微服务设计 - api版本控制

要描述了几种API版本控制的方法。用户可以查询原始的API，或者添加定制的头文件来接收特定的版本。如果应用程序收到一个重大修订，将URI修改为V2。在进行迭代改进时，将创建与更改日期相一致的端点，并允许用户将日期信息附加。然后，可以选择保留旧版本的时间。而且在设计和版本化API时，您可以应用许多不同的理念。以下为译文

API设计是一个“火辣热门”的话题！关于API的最佳结构和版本的方法已经有很多优秀的文章介绍过了。在这篇文章中，我们将会深入研究不同的API设计之间有哪些冲突的地方，并在此基础上提出我们的中立观点，然后展示我们是怎样使用FLY去验证我们的中立观点的。

API版本控制
虽然没有一个统一的方式来设计API，但是有必要明确一下许多开发人员同意的几个关键想法。一个结构良好的Web API应该是…

1：与客户端保持持续的协议。协议可以保证一致性和稳定性；客户端应该可以使用API，而不用担心它会突然中断或消失。

2：更改或升级后向后兼容。对新端点的旧查询仍应产生预期的返回值。

3：RESTful（互联网应用程序）。它应当可以识别HTTP的相关动作 ：GET，PUT，POST，PATCH，DELETE等。

为了最好地实现这些理想的要求，在如何实现不同版本的API上就是仁者见仁，智者见智了。我们来看看它们中的三个…

URI版本控制

curl https://example.com/api/v2/lists/3 

通过解除URI中的版本号，客户端可以访问/v1/或/v2/API。它可读，适应性强，可直接插入用户浏览器。

Header版本控制

curl https://example.com/api/lists/3 \
-H 'Accept: application/vnd.example.v2+json'

API URI保持不变。头版本控制主要是通过自定义的Accept HTTP头来完成的。核心URI仍然保持不变，但是能最好表示出API的资源，并且版本的更改将通过头和响应类型传递。

没有版本控制！

curl https://example.com/api/lists/3  

你需要什么版本？让我们扩展我们的API以适应新的或调整的案例！放弃旧的框架，选择建立和扩展。

中立观点
每一个方法都是合理的，如果有好的设计思路的话，它们都可以呈现优异的API。 最终，我们希望它们都能实际运用起来，尽可能快地传输信息。一个没有版本控制的绿色API可能会变得混乱，所以我们将远离这一点。相反，我们将接受URI和HTTP标头中的版本控制。作为一个转折，我们将使用一个自定义的HTTP头。

为了避免出现连我们自己都无法了解为什么请求会如此混乱且冗长的情况出现，让我们更深入地了解一下为什么我们要使用这种方法。我们的方法是基于这样一句格言:随着太阳的升起，你的应用将会改变。

参考：https://blog.csdn.net/qiansg123/article/details/80130050