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

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">
...

当您对合同进行可破坏的更改(例如删除操作)时,您会破坏所有现有客户端,这是一个很大的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其特定的有效负载参数转换为业务层的适当参数.通过这种方式,所有呼叫都汇聚到业务层,此时通常不关心客户端是哪个版本.

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