微服务设计 - 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