關於如何版本化REST Web服務似乎有一場持續的哲學辯論。但對我來說，第一個問題是實際問題，它是如何在基於Java servlet的後端中實現和維護的難易程度。我的公司正在構建一個新的REST Web服務，雖然目前我們並不擔心對它進行版本控制，但我不想做出一個讓我們陷入困境的架構決策。對基於Java的REST Web服務進行版本控制？
我想我們現在必須做的主要決定是我們應該把版本標識符放在我們的URI還是媒體類型（或兩者）中。如果它的相關，我們將只有少數新的媒體類型。此外，該應用程序還有50多個資源URI。
每種方法相對於在我們的Java servlet中實現它們有哪些優缺點？
我最初的想法：
1）我喜歡版本媒體類型（例如「的想法應用/ vnd.mystuff + xml的;版本= 1.0」），因爲感覺相同版本的XML模式用於SOAP/RPC Web服務。另外，看起來像conneg只是爲了這樣的事情而設計的。然而，似乎要實現這一點將是困難的，如果不是不可能的話，因爲我們的應用程序是由領域驅動的設計主體創建的，我們不能只創建新版本的Java類，並讓它們與舊的版本坐在一起。所以我們必須實現新的Java類，然後手動編寫JSON/XML序列化/反序列化來支持所有舊版本的媒體類型。我想這與SOAP版本化XML Schema沒有什麼不同......
2）另一方面，如果我們要對URI的版本（例如「http://ourapp.com/v1/mystuff」）進行版本化，那麼我們的客戶可以部署系統的兩個完整版本，並將它們作爲兩個獨立的具有不同上下文映射的servlet來站立。但是，我們將修改v1 Java類的JPA（ORM）映射以使用v2 RDBMS模式。這可能並不總是很簡單，但我可以很容易地理解它是如何完成的。然而，這種方法讓我感到困惑，因爲「application/vnd.mystuff + xml」將返回兩種不同的XML模型，這兩種模型對應於兩種不同的XML模式。但也許這並不重要，因爲客戶端知道它要求什麼，因爲它使用了v1或v2 URI ......
或者是否有更容易實現的替代方法，我們沒有考慮？或者可以在整個問題上發揮作用並在以後擔心？
在我看來，使用不同的URI更清晰，並且可以讓客戶更清楚地看到他使用的是什麼。對整個API進行版本控制比單個資源版本更合適（在來自同一個「代」的兩個資源之前的vX和vY會令人困惑）。這也是我見過的大公司最常用的方法（即雅虎，DropBox）。 – Viruzzo 2012-01-12 16:50:58
http://stackoverflow.com/questions/389169/best-practices-for-api-versioning – Michael 2012-01-12 16:52:41