向后兼容性和Web服务

Question

所以我对Web服务有点新意，最近出现了一个情况，我们在数据类型中添加了一个返回给客户端的元素。客户抱怨这打破了他们的实施，因为它扼杀了它没想到的新元素。 （我们通过Axis2提供服务。）

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

基本上我希望wsdl就像一个接口。如果我们进行基本上是接口的子类型的更改，我希望客户端愉快地忽略无关的元素。这只是网络服务的短暂出现，还是有一种理智的方式对服务进行被动更改，以便新客户可以获得额外的数据，而老客户可以在闲暇时更新？

Answer 1

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

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

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

1. 版本化WSDL定义并发布可以将旧版本重定向到较新版本的服务
2. 使用更多抽象数据返回类型（例如XML）来隐藏复杂性或更改数据。

2存在更多风险，但可以使用XSD或其他技术进行管理。您的特定项目要求将决定可接受的内容。

Answer 2

过去，在处理暴露的WebService 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

Answer 3

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

SOAP和代码生成的客户端代理会导致这些问题，因为它们会生成想要了解“整个架构”的客户端，而不仅仅是他们感兴趣的位。另一种方法是让他们使用Xml Parser然后拉出他们需要的部分。

如果您的Web服务正在开发或不断变化，那么SOAP实际上不是您的最佳选择，因为它意味着每次更改都需要重新生成，重建和重新部署其服务客户端。根据您的具体情况，您可能需要考虑提供REST + POX（Plain Old Xml）Web服务，因为它不易解析，因为它没有SOAP的开销，可以通过普通URL调用，并由环境消耗。没有SOAPClient库（例如直接在浏览器中，使用AJAX）

Answer 4

一个可能的答案是使用替换组在您导入的XSD中启用抽象模型。 处理此类替换组的可能性仍需要使用您用于调用这些服务的框架进行验证。