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

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

例如：

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

---

注意：我所说的“struct”是指复合类型，它不是。你必须以某种方式手动管理它。通常通过在引入主要/突破性更改时创建新接口

---

更一般地说，这是一个体系结构问题，而不是技术问题。一旦发布了接口，您真的需要考虑如何处理更改。

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

编辑：

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

• 将参数添加到现有函数中-如果参数是可选的，那么如果客户端不发送它，您将获得一个

  null

  值
• 向现有函数中使用的现有结构中添加变量-如果该值是可选的，则如果客户端不提供该值，则会得到

  null

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

---

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

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