我的意思是可演变性是向服务添加新功能或修改(如果有可能)现有的功能,实际上是这样.
SOAP并不是那么糟糕,因为当涉及到可演变性时,REST社区倾向于谈论它.例如：
>在REST中,我们可以添加新的rel-in SOAP,我们可以添加新的方法.都
旧客户类型将继续使用新服务.
>在REST中,我们可以添加新的表单域并设置其默认值
SOAP我们可以将服务参数作为一些ServiceArgs类和
向ServiceArgs添加一个新字段.这很丑,但它有效.
当SOAP客户端破裂时,可执行的示例是什么,您可以不做任何事情,而REST客户端正在适时地处理这种情况？
谢谢！
SOAP是基于合同的技术.整个客户/服务器交互写在一个大文件(WSDL)中,并且必须得到双方同意和尊重,才能使事情发生.如果任一方决定添加功能,另一方必须与其进行锁定步骤“演进”.双方完全结合,在臀部加入,粘在一起,结婚,永远.增强SOAP服务的典型方法是为新版本的服务创建新的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 …媒体类型,客户端可以选择(使用HTTP中的Accept和Content-Type标头)他们想要使用哪一个.
有没有听说过有关保时捷车主的笑话,每当烟灰缸充满时,谁买了一辆全新的车？那是SOAP.应该是一个微不足道的变化需要大修. REST给你真空吸尘器.你不必使用它,但它肯定是便宜的.