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

尝试了解 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 服务有多个版本，您最终可能会收到版本 X 的有效负载，但标记为版本参数值 Y)。

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

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

当你做对您的合同进行重大变更 https://stackoverflow.com/questions/8786935/what-are-considered-non-breaking-or-backwards-compatible-changes-to-a-wsdl-contr（就像删除一个操作）你破坏了所有现有的客户端，这是一个很大的NO NO，因为你基本上使你的网络服务不可调用，因此毫无用处。

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

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

你们继续支持v1对于现有客户，同时使用v2迎接所有新客户的到来（幸运的是，随着时间的推移，您的v1客户可以迁移到v2).

当您需要支持多个版本时，您基本上需要管理端点。此时你可以采取两种方式。

您可以维护一个端点，例如www.company.com/service/它接收所有消息（v1 and v2）并充当外观，根据消息命名空间重定向到正确的实现或...

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

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

希望现在更清楚了...