2

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

4

1 回答 1

7

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

出于这个原因，最好使用合约模式的命名空间来强制执行版本，例如：

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

当您对合同进行可破坏的更改（例如删除操作）时，您会破坏所有现有的客户端，这是一个很大的 NO NO，因为您基本上使您的 Web 服务不可调用，因此无用。

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

...
<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其特定的有效负载参数转换为适当的参数。通过这种方式，所有调用都汇聚到业务层，此时业务层通常不关心客户端是哪个版本。

希望现在更清楚...

于 2012-11-10T15:14:54.500 回答