版本ASP.NET 2.0 Web服务的最佳方法是什么?

在一般情况下,对Web服务进行版本控制不仅仅是对方法名和.asmx文件名进行版本控制。理想情况下,到Web服务(其WSDL)的接口应该是一个永久的契约,并且永远不应该更改。其中一个影响是,不需要更改功能的客户机永远不需要更改,因此也不需要重新测试。

您应该创建一个包含已更改操作的新合同,而不是破坏现有合同。该合同可以“继承”现有合同,也就是说,您可以“将方法添加到末尾”。但是,请注意,您还应该将新契约放入一个新的XML名称空间中——名称空间基本上标识了WSDL,并且keping了名称空间,但是更改WSDL是一个谎言。

然后,您应该在一个新的端点(.asmx文件)上实现这个新契约。不管这是在不同的目录中,还是在不同的网站上,都不重要。重要的是,需要新功能的客户机可以在新的URL上引用新的WSDL,并在新的URL上调用新的服务,并且感到高兴。

请注意,更改现有合同的一个影响是,下次执行“更新Web引用”时,您将 改变 客户端代理类的代码。在大多数商店中,更改代码需要重新测试和重新部署。因此,您应该将“只是添加方法”视为“只是添加一些必须测试和部署的客户机代码”,即使现有客户机代码不使用新方法。

我们部署到版本目录,例如:

http://www.example.com/soap/v1/ http://www.example.com/soap/v2/ http://www.example.com/soap/v3/

等。

我刚刚想到了另一个可能的解决方案,看起来很干净。

我可以检查作为SOAP头包含的版本号,如果没有提供,则假定使用现有的版本号。

然后,我可以使代码在不同版本中的行为有所不同,而无需更改方法签名。这是可能的,因为来自Web服务的返回值是XML对象,所以方法签名保持不变,但XML的内容根据版本而更改。

我在开发的WebServices中有相同的版本控制问题。我们让用户在头部传递一个模式版本号。他们告诉我们他们想要返回的XML模式的版本。这样,我们总是向后兼容,代码不会重复。

在我的工作中,我们无法告诉客户机,当我们对其进行版本设置时,他们必须将URL切换到WebService。在大公司中,像URL这样小的更改可能需要几个月的测试。我觉得你不应该破坏与客户的联系。我们要做的是,在最新版本中添加新功能。当客户机请求新功能时,如果他们需要,他们将被迫升级到最新的模式。

除非您用每个新版本更改大多数方法签名,否则我将使用(a)版本的方法名称。我们的供应商就是这样做的,这对我们来说很好。