的REST API的版本，當你有相同的域

我設計一些的REST API，這將是訪問下api.ourdomain.com/ 有將要在多個API的幾個API的像的REST API的版本，當你有相同的域

api.ourdomain.com/Provider/ 
api.ourdomain.com/Consumer/ 
api.ourdomain.com/Customer/ 
api.ourdomain.com/Authorization/

等，這些不是資源，而是非常獨立的API，在我們的api子域下面。

現在我有困惑是，

應我繼續使用，

api.ourdomain.com/Provider/v1/resource/etc/

或

api.ourdomain.com/v1/Provider/resource/etc/

所以，真正的問題是，它在哪裏適當放版本，後名稱的API

[/提供者/ V1/XYZ /等]

或從組織的角度來看，API類型的提供V1

[/ V1 /提供者/ XYZ /等]

不限建議表示讚賞謝謝。

就我所知，這裏沒有任何約定。下面是谷歌，雅虎和微軟的API的例子：

我更傾向於將離開版本末（如谷歌）的所有道路。這樣，大部分網址保持不變，只有最後一部分被更改。再次，這只是我的偏好，而不是慣例。

2012-03-23 00:05:01 stepanian

這不能以一般方式回答，但我相信針對您的案例的答案可以由預期的客戶端應用程序很好地確定，因爲您處於受限環境中，並且您知道API的業務案例。

如果您的客戶端應用程序需要跨「提供者」和「消費者」子域工作，例如，我建議將版本放在API根目錄中（$ SERVER/$ VERSION/$ SUBDOMAIN）子域分開並沒有多大意義。從客戶端角度來看，API作爲一個單一的實體。（在源代碼中，你有一個常量「apiVersion」）。

如果每個端點將被不同的客戶端應用程序使用（例如移動應用程序用於「提供者」的「消費者」和桌面客戶端系統），我建議版本控制子域（$ SERVER/$ SUBDOMAIN/$ VERSION），因爲不同的開發速度可以應用於各種系統，並且系統或多或少是獨立的。

值得注意的是，第二個方法是更加靈活，可以映射到第一個1：

$SERVER/1.0/$SUBDOMAIN_A/ 
$SERVER/1.0/$SUBDOMAIN_B/

可以很容易地改寫爲==>

$SERVER/$SUBDOMAIN_A/1.0 
$SERVER/$SUBDOMAIN_B/1.0

我會去那麼第二種方法只是爲了更安全 - 即使你同時升級所有的API，這也是可行的。

遵循的一般規則是執行良好的API設計並儘可能避免不兼容的更改，這些更改會強制您升級API版本。

更新：還有一件事 - API依賴的概念。例如，如果您升級API以進行身份驗證，以便需要新的API版本，則所有客戶端也需要升級，您可能需要單獨對該API進行版本升級。這是第二種方法的另一點...

希望可以幫助...

2012-06-22 13:47:00 joshis

回答