关于如何版本化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