REST 与 SOAP 可演化性答案

【问题标题】：REST vs SOAP evolvabilityREST 与 SOAP 可演化性
【发布时间】：2012-02-18 02:11:30
【问题描述】：

我得到了更改链接 uri 的好处，但这真的不是这个问题的目的。

我所说的可进化性是指向服务添加新功能或修改（如果可能）现有功能，实际上就是这样。

SOAP 并没有那么糟糕，因为 REST 社区在谈到可演化性时倾向于谈论它。例如：

在 REST 中我们可以添加新的 rel - 在 SOAP 中我们可以添加新方法。两个都老客户类型将继续使用新服务。
在 REST 中，我们可以添加新的表单字段并设置其默认值 - 在 SOAP，我们可以将服务参数作为一些 ServiceArgs 类和向 ServiceArgs 添加一个新字段。这很难看，但它有效。

当 SOAP 客户端中断并且您无能为力，而 REST 客户端正在优雅地处理这种情况时，有哪些可演化性示例？

谢谢！

【问题讨论】：

标签： rest soap rpc

【解决方案1】：

SOAP 是一种基于合同的技术。整个客户端/服务器交互都写在一个大文档（WSDL）中，并且必须得到双方的同意和尊重才能正常工作。如果任何一方决定添加功能，另一方必须与其同步“进化”。双方完全结合，在臀部连接，粘在一起，结婚，永远。

增强 SOAP 服务的典型方法是为新版本的服务创建新的 WSDL 文档，同时维护旧版本。另一种技术是创建一个新接口来包含新方法并从旧方法继承。您在 #1 中描述的方法是 IMO 打破了 SOAP 规则，因为客户端和服务器现在将使用不同的合同，并且它只起作用是因为 additive 更改（如新方法）可以被硬塞进去大多数时候事情都会奏效。一旦有人进行了破坏性更改，那么客户端的合同将与服务器的合同不匹配，游戏就结束了。这是一个难以管理的过程，这就是为什么大多数组织选择为每个新版本的 API 创建全新的 WSDL。

REST 不会神奇地解决所有这些问题，但它不会强迫您将整个分布式系统的“合同”捆绑到一个工件中，从而使事情变得更容易管理。您使用的是 HTTP 吗？太好了，那么您就可以使用 Web 也使用的所有美妙的 HTTP 功能：代理服务器、URL、内容协商、身份验证等。您想使用 JSON 编码和 XML 进行通信吗？把自己打昏。任何时候都可以在 REST 中进行操作，而不会影响现有客户端。你想要安全吗？好的，开始使用 HTTP 的内置支持来挑战经过身份验证的凭据。所有这些东西（HTTP、JSON 等）都是标准化的，并在不同的地方进行了描述，而这正是它应该的样子。

SOAP 将传输协议、位置信息、有效负载描述、编码选择和 RPC 方法组合到一个巨大的文档中。如果您想对该列表中的任何内容进行任何更改，则需要一个新文档。更糟糕的是，其中一些东西根本无法改变。

REST 将这些东西分开，以便这些部分可以独立发展。您的 URL（或者更准确地说是“URI”）在运行时返回，并假设客户端 doesn't start to hardcode them 是可进化的，无需对客户端进行任何更改。如果您的文档清楚地表明将来可能会出现新字段，那么对您的媒体类型进行附加更改是微不足道的。您还可以选择对媒体类型进行版本控制，允许 v1/v2/v3... 媒体类型在您的系统内共存，并且客户端可以选择（使用 Accept 和 Content-Type 中的标头HTTP) 他们想使用哪一个。

你听过保时捷车主在烟灰缸满了就买新车的笑话吗？那是肥皂。应该是微不足道的改变需要大修。 REST 为您提供真空吸尘器。您不必使用它，但它肯定更便宜。

【讨论】：

感谢您的扩展答案。显然 SOAP 服务不如 RESTful 服务可进化。然而 SOAP 确实允许某种程度的可演化性。你不能改变格式和其他一些东西，但你可以添加方法和参数（上面描述的一个小技巧）。正如您所说，这将违反 SOAP 规则，但这有关系吗？有用。您还说，当有人对 SOAP 服务进行破坏性更改时，游戏就结束了。它也适用于 RESTful 服务。如果您对媒体类型进行了破坏性更改，并且客户端找不到链接，那么它也期望它是 kaput。
Re：向 SOAP 接口添加方法（“技巧”）：是的，它有效，但它的有效是因为运气，而不是设计。它本质上是一种不受支持的技术。使用 REST，您的架构可以进化，因为进化是 REST 的核心，而不是像 SOAP 那样在基本级别被禁止。回复：破坏性更改 - 两个帐户都正确。这不是任何程序化客户端都能神奇地处理的事情。