微服務設計 - 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