SOAP/WSDL 中的 API 能否轻松保持向后兼容？答案

【问题标题】：Can an API in SOAP/WSDL be kept backwards compatible easily?SOAP/WSDL 中的 API 能否轻松保持向后兼容？
【发布时间】：2010-01-29 11:22:20
【问题描述】：

使用 IPC 库时，重要的是它提供了客户端和服务器都可以通信的可能性，即使它们的 API 版本不同。当我考虑将 SOAP 用于我们的客户端/服务器应用程序时，我想知道 SOAP/WSDL 解决方案是否可以很好地处理 API 更改。

例如：

向现有函数添加参数
向现有函数中使用的现有结构添加变量
删除函数
从现有函数中删除参数
从现有函数中使用的现有结构中删除变量
更改现有函数中使用的参数类型
更改现有函数中的参数顺序
更改现有结构中复合部件的顺序
重命名现有函数
重命名参数

注意：“结构”是指复合类型

【问题讨论】：

我认为你的意思是 RPC - 不是 IPC？
@troelskn：是的。对我来说，这些都是同义词。

标签： soap wsdl backwards-compatibility

【解决方案1】：

据我所知，没有符合 SOAP/WSDL 标准的东西。但是存在解决此类问题的工具。例如，在 Glassfish 中，您可以指定 XSL 样式表来转换 Web 服务的请求/响应。其他解决方案（例如 Oracle SOA 套件）提供了更精细的工具来管理 Web 服务的版本控制和组件的集成。消息可以自动路由到不同版本的网络服务和/或转换。您需要检查您的目标基础架构提供什么。

编辑：

XML 和 XSD 在模式演变方面比面向对象语言中的类型和序列化更灵活。有些东西可以通过简单地将它们声明为可选来向后兼容，例如

向现有函数添加参数 - 如果参数是可选的，如果客户端不发送，您将获得 null 值
将变量添加到现有函数中使用的现有结构 - 如果该值是可选的，如果客户端不提供，您将获得 null
删除函数 - 这里没有魔法
从现有函数中删除参数 - 根据新定义，客户端发送的参数将是多余的，将被省略
从现有结构中删除现有函数中使用的变量 - 在这种情况下我不知道
更改现有函数中使用的参数类型 - 这取决于更改。对于简单类型，序列化/反序列化可能仍然有效，例如字符串转 int。

请注意，我不能 100% 确定该列表。但是一些测试可以告诉你什么有效，什么无效。关键是 XML 是通过网络发送的，因此它提供了一些灵活性。

【讨论】：

非常感谢您的回答！然而，我突然意识到我忘了提另外两个案例：重命名函数和重命名参数。你知道在这些情况下会发生什么吗？
在这种情况下，XML 将不兼容，因此无法正常工作。我认为您将需要转换消息，例如使用 XSLT。
但是如果你交换两个参数的顺序，你的 web 服务仍然是兼容的，这不会是 Java 或 .NET 接口的情况。
"交换两个参数的顺序"：确实；另一个我忘了提：s
您只是在谈论 API 的“新”方面，“旧”呢？是否有 SOAP 端点处理请求（或 SOAP 客户端和响应）中的其他未知标签的做法？

【解决方案2】：

它没有。您必须以某种方式手动管理它。通常是在您引入重大/重大更改时创建一个新界面。

更一般地说，这是一个架构问题，而不是技术问题。接口发布后，您确实需要考虑如何处理更改。

【讨论】：