Web services 向后兼容性和Web服务

所以我对web服务有点陌生，最近出现了一种情况，我们向返回给客户机的数据类型添加了一个元素。客户抱怨说，这破坏了他们的实现，因为它阻塞了它没有预料到的新元素。（我们通过Axis2提供服务）

对我来说，这似乎是一个无害的变化，客户端应该能够优雅地处理（我曾经使用过一些非web服务框架，在这些框架中添加可选信息是完全可以接受的）。如果我们删除或重命名了一些会给客户端带来问题的字段，我可以理解

---

基本上，我希望wsdl像接口一样工作。如果我们做了一个本质上属于该接口子类型的更改，我希望客户机愉快地忽略无关的元素。这仅仅是web服务的短期发展，还是有一种明智的方法对服务进行被动更改，以便新客户端可以获得额外的数据，而旧客户端可以在空闲时进行更新？

过去，在处理公开的web服务API时，我一直遵循日期版本控制的理念。不幸的是，一旦退出“beta”模式（有时甚至是那时），您就必须处理向公众发布的任何API的向后兼容性问题

我们所做的很简单；在新API发布的那天，我们会创建一个文件夹结构，如下所示：

http://mydomain.com/path/to/service/2009/12/17/servicename.svc

这样，我们只需检查文件夹结构就可以知道哪个版本是最新的，我们的客户在准备升级之前不必担心破坏更改。像冠军一样为我们工作；我唯一可能改变的是使用一个文件夹，这样它们就更容易一起查看：

http://mydomain.com/path/to/service/2009-12-17/servicename.svc

---

WSDL实际上是一个契约，而不是一个接口。WSDL准确地描述了操作期望“接收”的内容和期望“返回”的内容。与此最接近的类比是C在不改变函数本身的情况下改变函数的原型，它们不匹配，这会导致问题

WSDL越具体，您“保证”的行为就越多

如果您需要灵活处理返回的数据（即添加/删除字段等），您可以执行以下操作之一：

版本您的WSDL定义和发布服务，可以将旧版本重定向到新版本

使用更抽象的数据返回类型，如XML来隐藏复杂性或不断变化的数据

---

2的风险更大，但可以使用XSD或其他技术进行管理。您特定的项目需求将决定什么是可接受的。

WSDL实际上是您发布的web服务SOAP接口。许多客户机使用它来生成他们的客户机代理，这些代理在他们选择的编程语言中公开您的所有webservice方法。大多数这些代码生成的客户机都非常脆弱，如果他们看到不可识别的元素（即，它不在WSDL中），就会选择抛出异常，而不是忽略它。有些人更放松，这实际上取决于他们使用的客户端技术，即Microsoft的新DataContract在其客户端上具有IEExtensibleData接口，专门保存他们无法识别的数据，因此他们将在很大程度上忽略未知元素

SOAP和代码生成的客户端代理容易出现此类问题，因为它们生成的客户端希望了解“整个模式”，而不仅仅是他们感兴趣的位。另一种方法是，他们使用Xml解析器，只需提取所需的位

---

如果您的web服务正在开发中或不断变化，那么SOAP确实不是您的最佳选择，因为这意味着每次变化都需要重新生成、重建和重新部署服务客户机。根据您的情况，您可能需要考虑提供REST + POX（普通的旧XML）Web服务，因为它更简单，因为它没有SOAP开销，可以通过一个正常的URL调用，并被没有SOAPCuffe库（例如直接在浏览器中使用Ajax）的环境所消耗。

一个可能的答案是使用替换组在您导入的XSD中启用抽象模型。

---

处理这样一个替代组的可能性仍然需要使用您用来调用这些服务的框架进行验证。

我做了一些非常类似的事情，只是我更喜欢使用明确的版本号（例如）只有当API以不向后兼容的方式更改时，才会对其进行碰撞。我建议，客户端可能正在伪造它，而没有使用SOAP接口，可能会通过一些可怕的手动解析/正则表达式伪造来解析响应（有这么多人这么做，真是令人惊讶）。我这样说是因为我经常在Unix和Windows系统（用于web应用程序、服务器端和桌面客户端应用程序）上用C#、PHP、Perl和JavaScript创建构建客户端和服务器SOAP接口，并且从未遇到过这个问题（在请求或响应中添加可选字段从未导致过问题）。我会问他们使用的是什么SOAP客户端。：-）我一定不同意上面的说法，因为我从来没有在使用PHP的SOAPClient、C#（Mono/.NET）或Perl SOAP库或JavaScript的请求/响应中遇到过其他元素的问题（我注意到JavaScript中至少有一个非常好的跨浏览器SOAP客户端）。面向公共接口的REST选项对于mashup之类的东西来说是很有价值的工具，但是SOAP是web服务更好的编程方法。莱恩，如果您使用的是SOAP客户端，那么您就没有使用WSDL生成的代码，那么您所做的就是使用智能Xml解析器跳过SOAP头来获取有效负载（当然，使用动态语言不会出现解析器错误）。如果是这种情况，那么SOAP web服务增加的性能开销和复杂性究竟有什么好处呢？您的前提是无效的，因为SOAP客户机是d