简体繁体 English

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

[英]What is the best way to Version an ASP.NET 2.0 Web Service?

原文 2009-05-29 11:20:38 1 5 .net/ asp.net/ soap/ versioning

I am maintaining a SOAP web service (ASP.NET version 2.0) and I have to make some changes that will modify the return values of particular methods. 我正在维护SOAP Web服务（ASP.NET 2.0版），我必须进行一些修改，以修改特定方法的返回值。

What is the generally accepted method of doing this without breaking existing implementations. 在不破坏现有实现的情况下，通常接受的方法是什么。

My initial thoughts are that the following would all be possible. 我最初的想法是，以下一切都是可能的。

a) Provide new version specific methods within the existing web service eg getPerson_v1.4 a）在现有Web服务中提供新版本特定方法，例如getPerson_v1.4
b) Provide a complete copy of the .asmx file with a new version number eg http:/www.example.com/AdminWS_V1_4.asmx. b）提供带有新版本号的.asmx文件的完整副本，例如http：/www.example.com/AdminWS_V1_4.asmx。 This is not an idea I relish as the service has more than 50 methods and copying that code for changes to 2/3 methods seems like too much duplicated code. 这不是我喜欢的想法，因为该服务有超过50种方法，并且复制代码以更改2/3方法似乎是太多重复的代码。
c) Override the web-service constructor to allow passing in a version number. c）重写Web服务构造函数以允许传入版本号。 This does not seem to work, and on reflection I'm not sure how that would be represented within a WSDL 这似乎不起作用，并且在反思时我不确定如何在WSDL中表示它

Is there a generally accepted way of doing this, or do people have advice based upon their experiences in this area. 是否有一种普遍接受的方式，或者人们根据他们在这一领域的经验提出建议。

5 个解决方案

We deploy to version directories, for example: 我们部署到版本目录，例如：

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

etc. 等等

In the general case, there's more to versioning a web service than just versioning method names and .asmx file names. 在一般情况下，对Web服务进行版本控制不仅仅是对方法名称和.asmx文件名进行版本控制。 Ideally, the interface to a web service (its WSDL) should be a permanent contract, and should never change. 理想情况下，Web服务（其WSDL）的接口应该是永久合同，并且永远不应该更改。 One of the implications would be that clients that do not need the changed functionality would never need to change, and therefore would never need to be retested. 其中一个含义是不需要更改功能的客户端永远不需要更改，因此永远不需要重新测试。

Instead of breaking the existing contract, you should create a new contract that contains the changed operations. 您应该创建一个包含已更改操作的新合同，而不是破坏现有合同。 That contract could "inherit" from the existing contract, ie, you could "add the methods to the end". 该合同可以“继承”现有合同，即您可以“将方法添加到最终”。 Note, however, that you should also put the new contract into a new XML namespace - the namespace basically identifies the WSDL, and keping the namespace but changing the WSDL would be a lie. 但是请注意，您还应该将新合同放入新的XML命名空间 - 命名空间基本上标识了WSDL，并且键入命名空间但更改WSDL将是一个谎言。

You should then implement this new contract at a new endpoint (.asmx file). 然后，您应该在新端点（.asmx文件）中实现此新合同。 Whether or not this is in a different directory, or even on a different web site doesn't really matter. 这是否在不同的目录中，甚至在不同的网站上并不重要。 What matters is that clients who want the new functionality can refer to the new WSDL at the new URL and call the new service at its new URL, and be happy. 重要的是，想要新功能的客户可以在新URL处引用新的WSDL并在其新URL处调用新服务，并且很高兴。

Be aware that one effect of changing an existing contract is that the next time an "Update Web Reference" is performed, you will be changing the code of the client proxy classes. 请注意，更改现有合同的一个效果是，下次执行“更新Web引用”时，您将更改客户端代理类的代码。 In most shops, changing code requires re-testing, and redeploying. 在大多数商店中，更改代码需要重新测试和重新部署。 You should therefore think of "just adding methods" as "just adding some client code that has to be tested and deployed", even if the existing client code does not use the new methods. 因此，您应该将“仅添加方法”视为“只添加一些必须进行测试和部署的客户端代码”，即使现有客户端代码不使用新方法也是如此。

I've just thought of another possible solution which seems quite clean. 我刚刚想到了另一个看似相当干净的可能解决方案。

I could check for a version number included as a SOAP Header and assume the existing version number if this is not provided. 我可以检查包含为SOAP标头的版本号，并假设现有版本号（如果未提供）。

I can then make the code behave differently for different versions without changing the method signatures. 然后，我可以在不更改方法签名的情况下使代码对不同版本的行为有所不同。 This is possbile as the return values from the Web-Services are XML objects so the method signature remains the same but the content of the XML changes based on version. 这可能是因为Web服务的返回值是XML对象，因此方法签名保持不变，但XML的内容基于版本而更改。

I have the same versioning issue with webservices that I am developing. 我正在开发的webservices具有相同的版本问题。 We make our users pass a schema version number in the header. 我们让用户在标头中传递架构版本号。 They tell us which version of the XML schema they want back. 他们告诉我们他们想要回复哪个版本的XML模式。 This way, we are always backwards compatible and code is not duplicated. 这样，我们总是向后兼容，代码不重复。

At my job, we cannot tell the client that they have to switch the URL to the webservice when we version it. 在我的工作中，我们不能告诉客户他们在我们发布版本时必须将URL切换到web服务。 In big corporations, changes as small as a URL could take months of testing. 在大公司中，像URL一样小的变化可能需要数月的测试。 It is my feeling that you should not break your clients connection. 我觉得你不应该破坏你的客户联系。 What we do is, add new features to the latest version. 我们所做的是，为最新版本添加新功能。 When the client asks for the new features, if they want them, they are forced to upgrade to the newest schema. 当客户端要求新功能时，如果他们需要，他们将被迫升级到最新的架构。

Unless you change most of the method signatures with each new version, I'd go with (a) - versioned method names. 除非您使用每个新版本更改大多数方法签名，否则我将使用（a） - 版本化的方法名称。 This is how our providers do it and it's working fine for us. 这就是我们的供应商如何做到这一点，它对我们来说很好。