版本控制 SOAP 主体与整个服务？答案

【问题标题】：Versioning SOAP body vs entire service?版本控制 SOAP 主体与整个服务？
【发布时间】：2012-11-09 19:30:49
【问题描述】：

试图了解 SOAP 和 Web 服务的版本控制。从我的发现来看，用 URL 做这样的事情似乎是可以接受的：

www.company.com/service/01-12-10/ 和 www.company.com/service/03-08-10/ 和 www.company.com/service/ 支持最新版本。

我知道这是要走的路，而不是像这样对 SOAP 主体/有效负载进行版本控制：

[client]

someRequest = newRequest(){ ClientVersion = "1.0.0" };
webService.Go(someRequest);

[web service]

if request.ClientVersion == "1.0.0"
  do this code
else
  do this code

我可以看到随着更改的发生所有条件将如何失控，并且当 Web 方法的签名被删除时，这并不能处理这种情况。然而，最重要的是，这不是对整个服务进行版本控制，而只是对正文进行版本控制。

所以，我的问题是我是否通过更改 URL 以包含版本来做对了？这是否涵盖了所有必要的领域？似乎我会有一些命名空间冲突？是否也需要更改命名空间？试图理解对服务进行版本控制意味着什么。请展开。

【问题讨论】：

标签： web-services soap versioning

【解决方案1】：

让客户端发送版本参数通常不是首选，因为您不能指望客户端发送正确的版本号（如果您有多个版本的 Web 服务，您最终可能会收到版本 X 的有效负载，但标有版本参数值 Y)。

因此，最好使用合约模式的命名空间强制执行版本，例如：

...
<types>
      <xs:schema xmlns="http://tempuri.org/v1"
                targetNamespace="http://tempuri.org/v1">
...

当您创建breakable changes to your contract（如删除操作）时，您会破坏所有现有客户端，这是一个很大的不可以，因为您基本上使您的网络服务不可调用，因此无用。

因此，当您进行主要版本更改时，您会公开一个您现在定义的新合同：

...
<types>
      <xs:schema xmlns="http://tempuri.org/v2"
                targetNamespace="http://tempuri.org/v2">
...

您继续为现有客户支持v1，同时为所有新客户使用v2（幸运的是，随着时间的推移，您的v1 客户可以迁移到v2）。

当您需要支持多个版本时，您基本上需要管理端点。在这一点上，你可以走两条路。

您要么维护一个端点，如 www.company.com/service/，它接收所有消息（v1 和 v2），并充当基于消息命名空间重定向到正确实现的门面，要么...

...您直接将版本公开为单独的端点，现有客户端将使用接收v1消息的旧端点（可能是www.company.com/v1/service/），而新客户端使用另一个仅接收v2消息的新端点（也许www.company.com/v2/service/)。

上述设置在您的（只有一个）业务实现上更容易，它通过您的 Web 服务的不同框架实现向客户公开。 v1 和 v2 的骨架将其特定的有效负载参数转换为业务层的适当参数。这样一来，所有的调用都会汇聚到业务层，此时业务层通常并不关心客户端是哪个版本。

希望现在更清楚......

【讨论】：