版本控制 SOAP 主体与整个服务? [英] Versioning SOAP body vs entire service?

问题描述

尝试了解 SOAP 和 Web 服务的版本控制.从我发现的情况来看，使用 URL 执行类似操作似乎是可以接受的:

Trying to understand versioning with SOAP and web services. From what I have found it seems acceptable to do something like this with the URL:

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

www.company.com/service/01-12-10/ and www.company.com/service/03-08-10/ and www.company.com/service/ support the latest version.

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

I understand this is the way to go as opposed to just versioning the SOAP body/payload like this:

[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 方法的签名被删除时，这不会处理这种情况.然而，最重要的是，这不是对整个服务进行版本控制，而只是对主体进行版本控制.

I can see how all the conditionals will get out of hand as changes are made AND that this does not handle the case when a web method's signature is removed. Most importantly, however, this is not versioning the entire service, just the body.

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

So, my question is did I get it right by just changing the URL to include the version? Does this enompass all the necessary areas? It just seems like I will have some namespace conflicts? Is it necessary to change the namespaces too? Trying to understand what it means to version the service. Please expand.

推荐答案

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

Having the client send a version parameter is usually not preferred because you can't count on the client to send the proper version number (if you have multiple versions of your web service you can end up receiving a payload for version X but marked with a version parameter value Y).

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

For this reason it's better to enforce the version with the namespace of the contract schema, something like:

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

当您制作 对合同的可破坏更改(例如删除操作)会破坏所有现有客户端，这是一个很大的问题，因为您基本上使您的 Web 服务不可调用，因此无用.

When you make breakable changes to your contract (like removing an operation) you break all your existing clients which is a big NO NO to do because you basically make your web service un-callable, thus useless.

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

So when you have a major version change you expose a new contract that you now define like:

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

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

You continue to support v1 for existing clients while using v2 for all the new clients to come (and luckily, with time your v1 clients can migrate to v2).

当你需要支持多个版本时，你基本上需要管理端点.在这一点上，你可以有两种方式.

When you need to support multiple versions, you basically need to manage endpoints. At this point you can go two ways.

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

You either maintain one endpoint like www.company.com/service/ which receives all messages (v1 and v2) and acts as a facade to redirect to the proper implementation based on the message namespace or...

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

... you directly expose the versions as separate endpoints and the existing clients will use an old endpoint that receives v1 messages (maybe www.company.com/v1/service/) while new clients use another newer endpoint that receives only v2 messages (maybe www.company.com/v2/service/).

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

The above setup is easier on your (only one) business implementation which is exposed to clients through different skeleton implementations of your web service. The skeletons for v1 and v2 transform their specific payload parameters into appropriate parameters for the business layer. In this way all calls converge into the business layer who at this point normally doesn't care which version the client was.

希望现在更清楚...

这篇关于版本控制 SOAP 主体与整个服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！