REST与SOAP的可演化性

Question

我得到了改变链接uris的好处,但这不是这个问题的关键所在.

我的意思是可移动性是为服务添加新功能或修改(如果可能)现有服务,实际上就是这样.

SOAP并不是那么糟糕,因为REST社区倾向于在可演化性方面谈论它.例如:

1. 在REST中我们可以添加新的rel-in SOAP,我们可以添加新方法.两种类型的旧客户端都将继续使用新服务.
2. 在REST中,我们可以添加新的表单字段并设置其默认值 - 在SOAP中,我们可以将服务参数作为一些ServiceArgs类,并向ServiceArgs添加一个新字段.这很难看,但确实有效.

什么是SOAP客户端中断的可演化性示例,而您无法对其执行任何操作,而REST客户端正在优雅地处理这种情况？

谢谢!

Answer 1

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")在运行时返回,并假设客户端没有开始硬编码它们是可以进行的,无需客户端进行任何更改.如果您的文档清楚地表明将来可能会出现新字段,则对媒体类型的添加更改是微不足道的.您还可以选择对媒体类型进行版本控制,允许在系统中共存v1/v2/v3 ...媒体类型,客户端可以选择(使用HTTP中的Accept和Content-Type标头)他们想要的使用.

有没有听过有关保时捷车主的消息,他们会在烟灰缸满载时买一辆全新的车？那是SOAP.什么应该是一个微不足道的变化需要进行重大改革.REST为您提供吸尘器.你不必使用它,但肯定更便宜.