向后兼容性和Web服务
因此，我对Web服务有点新，最近出现了一种情况，我们向返回给客户端的数据类型添加了一个元素。客户抱怨说，这打破了他们的实施，因为它窒息了它没有预料到的新元素。 （我们通过Axis2提供服务）。向后兼容性和Web服务
对我来说，这似乎是一个无害的变化，客户端应该能够正常处理（我已经与一些非Web服务框架一起添加可选信息是完全可以接受的）。我可以理解，如果我们删除或重命名某些会导致客户端问题的字段。
基本上我会期望wsdl的行为就像一个接口。如果我们做了一个基本上是这个接口的子类型的改变，我希望客户能够愉快地忽略无关的元素。这仅仅是网络服务的一个短暂来临，还是有一种对服务进行被动更改的理智方式，以便新客户可以获得额外数据，而旧客户可以在闲暇时进行更新？
WSDL实际上充当合同比界面更。 WSDL准确描述了操作期望“接收”的内容以及它期望“返回”的内容。与此最接近的比喻是C在不改变函数本身的情况下更改函数的原型，它们不会匹配并导致问题。
更具体的WSDL是你“保证”到位的行为越多。
如果您需要在返回数据的灵活性（即添加/删除字段等），你可以执行下列操作之一：
- 版本的WSDL定义和发布，可以重定向旧版本到新版本 服务
- 使用更多抽象数据返回类型，如XML来隐藏复杂性或更改数据。
2有更多的风险，但可以使用XSD或其他技术进行管理。您的特定项目要求将决定什么是可接受的。
在过去，当处理暴露的WebService API时，我一直使用日期版本管理原则。不幸的是，你必须处理向后公开的任何API的向后兼容性，一旦你退出“测试”模式（有时甚至是那样）。
我们所做的事情非常简单;当天的新API发布，我们会创建一个文件夹结构如下所示：
http://mydomain.com/path/to/service/2009/12/17/servicename.svc
这样，我们就知道哪个版本是最新的只是通过检查文件夹结构，和我们的客户不会有担心突破变化，直到他们准备升级。为我们工作就像一个冠军;我可能已经改变的唯一事情是使用一个单一的文件夹，这样他们会更容易查看全部一起：
http://mydomain.com/path/to/service/2009-12-17/servicename.svc
我做了一件非常相似的事情，除了我更喜欢使用明确的版本号（例如http：// http：//example.com/ServiceName/1.0/Service/）并且只在API更改时才使用它一种非向后兼容的方式。 – 2010-02-09 10:31:27
WSDL实际上是您的Web服务发布的SOAP接口。许多客户端使用它来生成他们的客户端代理，这些客户端代理以他们选择的编程语言公开所有webservice方法。这些代码生成的客户端大多非常脆弱，如果他们看到一个他们不认识的元素（即它不在WSDL中）而不是忽略它，就会选择抛出异常。有些人更放松，他们真正使用的是客户端技术，微软新的DataContract在其客户端拥有IExtensibleData接口，专门存储他们无法识别的数据，因此他们将很大程度上忽略未知元素。
SOAP和代码生成的客户端代理可以解决这些问题，因为它们生成的客户端想要理解“整个模式”而不是他们感兴趣的位。另一种方法是让他们使用Xml解析器，只是拔出他们需要的位。
如果您的Web服务正在开发或不断变化那么SOAP是真的不您最好的选择，因为它会与每一个变化，他们将不得不重新生成，重建和重新部署其服务客户的意思。根据您的情况，您可能需要考虑提供REST + POX（Plain Old Xml）Web服务，因为它更简单，因为它没有SOAP开销，可以通过普通URL调用，没有（直接在浏览器例如，使用AJAX）一个的SOAPClient库
我必须不同意以上所述，因为我从来没有使用PHP的SOAPClient，C＃（Mono/.NET）或Perl SOAP库或使用JavaScript的请求/响应中的其他元素的问题（我会注意到至少有一个漂亮的JavaScript中的跨浏览器SOAP客户端）。面向公共接口的REST选项对于混搭而言是很有价值的工具，但SOAP对于Web服务来说是一种更好的编程方法。 – 2010-02-09 10:45:19
Lain，如果您使用的是SOAP客户端，那么您不使用WSDL生成的代码，那么您所做的全部工作就是使用智能Xml解析器跳过SOAP头以获取有效内容（当然，您不会得到解析器错误与动态语言）。如果是这种情况，那么SOAP Web服务的额外性能开销和复杂性究竟有哪些好处？ – mythz 2010-02-09 18:38:23
由于SOAP客户端使用WSDL生成的代码，因此您的前提无效，当存在无关元素时，它们不会倾向于抛出错误。他们在实践中几乎都是这样工作的。这决不会否定使用SOAP的优点，因为锅炉板应该全部自动化。因此，我会反击非常容易实现（除非使用像RPC/Encoded格式那样可怕并且不推荐的东西，这使SOAP在复杂性方面名声不好）。 – 2010-02-12 15:25:59
一个可能的答案是使用替换组，使抽象的模型在XSD的导入。 处理这样的替换组的可能性仍然需要用您用来调用这些服务的框架来验证。
我建议有可能在客户端捏造，并没有使用SOAP接口，也许解析由一些可怕的手动解析/正则表达式软糖的反应（这是惊人的，有多少人做到这一点）。我说这是因为我经常在Unix和Windows系统上（用于Web应用程序，服务器端和桌面客户端应用程序）在C＃，PHP，Perl和JavaScript中创建构建客户端和服务器SOAP接口，并且从未遇到过这个问题（添加可选字段在请求或响应中从未造成过任何问题）。我会问他们使用什么SOAP客户端。 :-) – 2010-02-09 10:39:00