REST与SOAP的可演化性比较

Question

REST与SOAP的可演化性比较

restsoaprpc

17

我了解更改链接URI的好处，但这并不是这个问题所关注的重点。

所谓可扩展性，是指向服务添加新功能或修改（在可能的情况下）现有功能。这就是它的全部含义。

与REST社区所说的对于可扩展性的SOAP不那么糟糕。例如：

1. 在REST中，我们可以添加新的rel - 在SOAP中，我们可以添加新的方法。这两种类型的旧客户端将继续使用新的服务。

2. 在REST中，我们可以添加新的表单字段并设置其默认值 - 在SOAP中，我们可以将服务参数作为某个ServiceArgs类，并向ServiceArgs添加一个新字段。虽然比较丑陋，但它确实起作用。

当SOAP客户端出现问题而无法处理时，REST客户端能够优雅地处理的可扩展性示例是什么？

谢谢！

- Vitaly Stakhov

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Brian Kelly · Accepted Answer

SOAP是一种基于契约的技术。整个客户端/服务器交互过程都写在一个大型文档（WSDL）中，并且必须由双方同意并遵守才能正常工作。如果任何一方决定添加功能，则另一方必须与之同步“演变”。双方完全耦合，紧密相连，永远在一起。

增强SOAP服务的典型方法是为新版本的服务创建新的WSDL文档，同时保留旧文档。另一种技术是创建一个新接口以包含新方法并继承旧接口。你在#1中描述的方法我认为是违反SOAP规则的，因为客户端和服务器现在将使用不同的协议，而这只能因为可以将增量更改（如新方法）硬塞进去，大多数时候它们可以正常工作。但是，一旦有人进行破坏性更改，客户端的协议将与服务器的不匹配，那么就无法继续了。这是一个难以管理的过程，这就是为什么大多数组织选择为每个API的新版本创建全新的WSDL的原因。

REST不能神奇地解决所有这些问题，但它使得管理变得更加容易，因为它不强制你将整个分布式系统的“合同”捆绑成一个工件。你使用HTTP？太棒了，那么你就可以使用网络使用的所有精彩HTTP功能：代理服务器、URL、内容协商、身份验证等等。你想同时使用JSON编码和XML进行通信？随便你。在REST中随时进行这些操作都很简单，而不会影响现有的客户端。你想要安全性？好的，开始使用HTTP的内置支持来挑战认证凭据。所有这些东西（HTTP、JSON等）都是标准化并在不同的地方进行描述，这正是应该的。

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

REST将这些内容分离开来，以便各个部分可以独立演化。你的URL（或更精确地说，“URI”）在运行时返回，假设客户端不开始硬编码它们，则可以在不需要对客户端进行任何更改的情况下演进。如果您的文档明确说明未来可能会出现新字段，则对媒体类型进行添加更改是微不足道的。您还可以选择对媒体类型进行版本控制，在系统中同时存在v1 / v2 / v3 ...媒体类型，客户端可以使用HTTP中的Accept和Content-Type标头来选择他们想要使用的版本。

听说过保时捷车主买车时只因为烟灰缸满了吗？那就是SOAP。一个应该是微不足道的变化需要进行重大改变。REST为您提供了真空清洁器。您不必使用它，但肯定更便宜。