Web服务 – 名称值对SOAP/WSDL的优点

SOAP是一种消息传递协议.与REST一样,它与苹果有草坪拖拉机一样多.消息传递协议中您需要的一些东西是：

>标题和其他非内容“属性”.
>寻址 – 根据标题将消息路由到不同的服务器/接收者;
>通过排队和其他方法保证交付;
>加密,签名和其他安全功能;
>交易和编排;
>在单个消息中准确表示复杂的结构化数据;

…等等.这不是一个详尽的清单. WSDL主要为SOAP添加的内容是：

>通过合同提供可发现性,这是一种机器可读的“文档”形式,可以准确地告诉消费者发送消息所需的内容,并允许代理自动生成;
>对消息进行严格的自动架构验证,与XSD适用于XML的方式相同.

REST不是消息传递协议. REST是一个资源和行动系统.由于其他答案所概述的几个重要原因,它是许多架构的可靠选择.它与PayPal和flickr等“NVP”服务几乎没有任何关联.

PayPal的NVP API不是REST.对于不支持SOAP或难以支持SOAP的客户端,它是HTTP POST上的另一种类似RPC的消息传递协议.这不是我的意见,这是对事实的陈述. NVP中的一个领域实际上是METHOD.这显然是RPC的措辞.看看他们的UpdateRecurringPaymentsProfile的API,并试着告诉我,这有点舔有意义地描述为“资源”.它不是一种资源,而是一种操作.

特别是在PayPal的情况下,“NVP”(HTTP POST)API几乎在所有方面都不如SOAP API.它适用于不能使用SOAP的消费者.如果你可以使用它,你绝对应该.

而且我也不一定会为此抨击PayPal.我知道很多人都因为没有把“正确的”RESTful API放在一起而抨击他们,但这不是我所得到的.并非使用REST可以准确描述世界上的每项服务. PayPal实际上不是一个基于资源的系统,它是一个事务系统,因此我可以原谅他们的架构师和开发人员没有完美优雅的REST架构.这也许值得商榷,但它不是黑白的.没关系;如果需要,我只会使用SOAP系统.

比较一下,例如Twitter API.这是一个真正的REST服务.您可以在此API上执行的每个“操作”都被准确地描述为检索或提交特定类型的资源.资源是推文,状态,用户.在这种情况下,使用复杂的SOAP API实际上没有任何意义,因为你不是真的在发送消息,你不是在执行事务,而是只是要求特定的东西,而这些东西可以用一个URL来描述.唯一的区别是,不是获取HTML网页,而是获得一些XML或JSON数据;你提出要求的方式完全一样.

REST Web服务通常(总是？)使用HTTP GET来检索某些资源. Twitter正是这样做的. GET仍然使用“名称 – 值对” – 这是查询字符串,？q = twitterapi& show_user = true.之后的那些位？是名称 – 值对.这里有一个很好的例子,说明为什么要使用REST而不是SOAP;您可以将其连接到RSS源并获取流式更新.我可以把它变成Firefox中的Live Bookmark.或者我可以以JSON格式下载它并将其绑定到类似jqGrid的东西.有趣的是,请求不是使用“Name-Value Pairs”;有趣的是,它是一个简单的URL,可以被知道如何请求网页的任何东西使用.

因此,为了尝试总结我所说的所有内容,请以这种方式思考：

>如果要将数据公开或使用或作为永久资源公开,请使用REST API(如果可用).
>当系统本质上是事务性的和/或当您需要复杂消息传递协议可以提供的高级功能(如RM和寻址)时,请使用SOAP API.
>当没有SOAP API或者您无法使用SOAP API时,使用RPC API(其中包括几乎完全围绕HTTP POST建模的任何API).

希望能够解决一些困惑.