Question

尝试使用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来包含版本来实现的吗？这是否包含所有必要的区域？好像我会有一些命名空间冲突？是否有必要更改命名空间？试图了解版本服务的含义。请展开。

Answer 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/）的旧端点，而新客户端使用另一个仅接收{ {1}}消息（可能是v2）。

上述设置在您（仅一个）业务实现上更容易，该实现通过Web服务的不同骨架实现向客户端公开。 www.company.com/v2/service/和v1的骨架将其特定的有效负载参数转换为业务层的适当参数。通过这种方式，所有呼叫都会汇聚到业务层，此时通常不关心客户端是哪个版本。

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

版本化SOAP主体与整个服务？

1 个答案: