REST 与 SOAP 可演化性

Question

我得到了改变链接 uris 的好处，但这真的不是这个问题的意义所在。

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

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

在 REST 中我们可以添加新的 rel - 在 SOAP 中我们可以添加新方法。两个都
老客户类型将继续使用新服务。

在 REST 中，我们可以添加新的表单字段并设置其默认值 - 在
SOAP，我们可以将服务参数作为一些 ServiceArgs 类和
向 ServiceArgs 添加一个新字段。这很丑陋，但它有效。

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

谢谢!

Answer 1

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

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

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

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

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

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