我从改变链接uris中获益，但这不是这个问题的关键所在。
我的意思是可演化性是为服务添加新功能或修改（如果可能）现有服务，实际上就是这样。
SOAP并不是那么糟糕，因为REST社区倾向于在可演化性方面谈论它。例如：
当SOAP客户端中断并且您无法对其执行任何操作时，什么是可演化性示例，而REST客户端正在优雅地处理这种情况？
谢谢！
答案 0 :(得分：19)
SOAP是一种基于合同的技术。整个客户端/服务器交互被编写并编入大文档（WSDL），并且必须得到双方的同意和尊重才能使事情顺利进行。如果任何一方决定添加功能，则另一方必须与其锁定步骤“进化”。双方完全结合，在臀部连接，粘在一起，结婚，永远。
增强SOAP服务的典型方法是为新版本的服务创建新的WSDL文档，同时还要维护旧版本的WSDL文档。另一种技术是创建一个新接口来包含新方法并继承旧方法。您在＃1中描述的方法是IMO打破SOAP规则，因为客户端和服务器现在将使用不同的合同，它只能起作用，因为添加更改（如新方法）可能会出现问题。而且大部分时间都会有效。当有人进行破坏性更改时，客户的合同将与服务器的合同无关，而且游戏结束。这是一个难以管理的过程，这就是大多数组织选择为每个新版API创建全新WSDL的原因。
REST并没有神奇地解决所有这些问题，但是通过不强迫您将整个分布式系统的“合同”捆绑到一个工件，它使管理变得更容易。你在使用HTTP吗？好的，那么你可以使用网络使用的所有精彩的HTTP功能：代理服务器，URL，内容协商，身份验证等。你想使用JSON编码和XML进行通信？把自己打昏。在REST中随时执行它是微不足道的，不会影响现有客户端。你想要安全吗？很好，使用HTTP的内置支持开始挑战经过身份验证的凭据。所有这些东西（HTTP，JSON等）都是标准化的，并在不同的地方描述，而这正是应该如何。
SOAP将传输协议，位置信息，有效负载描述，编码选择和RPC方法组合成一个巨大的文档。如果要对该列表中的任何内容进行任何更改，则需要一个新文档。更糟糕的是，其中一些事情根本无法改变。
REST将这些内容分开，以便可以独立发展。您的URL（或更准确的“URI”）将在运行时返回，并假设客户端doesn't start to hardcode them可以进行转换，而无需对客户端进行任何更改。如果您的文档清楚地表明将来可能会出现新字段，则对媒体类型的添加更改是微不足道的。您还可以选择对媒体类型进行版本控制，允许系统中的v1 / v2 / v3 ...媒体类型共存，客户端可以选择（使用Accept和{{1 HTTP中的标头）他们想要使用哪一个。
有没有听过有关保时捷车主在玩烟灰缸满载时买一辆全新车的笑话？那是SOAP。什么应该是一个微不足道的变化需要进行重大改革。 REST为您提供吸尘器。你不必使用它，但肯定会更便宜。