WSDL与REST优点和缺点

有关:

为什么要使用REST而不是Web服务？

在决定是否使用SOAP或REST实现Web服务时(我以RESTful方式表示HTTP/XML)我应该注意什么以及我应该考虑什么？我认为这不是一个适合所有的东西,所以我该如何选择使用哪个.

1> Kekoa..：

---

这两种协议在现实世界中的用途非常不同.

SOAP(使用WSDL)是一种以文档传递为中心的重量级XML标准.这样做的好处是您的请求和响应可以非常好地结构化,甚至可以使用DTD.缺点是它是XML,并且非常冗长.但是,如果双方需要签订严格的合同(比如银行间通信),这就很好.SOAP还允许您在文档上对WS-Security等内容进行分层.SOAP通常与传输无关,这意味着您不一定需要使用HTTP.

REST非常轻量级,并且依赖于HTTP标准来完成它的工作.很高兴能够快速启动并运行有用的Web服务.如果您不需要严格的API定义,那么这就是您的选择.大多数Web服务都属于这一类.您可以对API进行版本更新,以便API的更新不会破坏使用旧版本的人(只要他们指定版本).REST本质上需要HTTP,并且与格式无关(意味着您可以使用XML,JSON,HTML等).

通常我使用REST,因为我不需要花哨的WS-*功能.如果您希望计算机使用WSDL了解您的Web服务,那么SOAP很好.REST规范通常只是人类可读的.

---

@JohnSaunders如果没有文件,为什么还有信封？我不认为我说DTD是SOAP的独特特征.对不起,我今天真的不想辩论.也许从大约3年前重新阅读你对这个问题的答案的评论.我认为重量不一定是坏事,有时你想要霍利菲尔德,但帕奎奥有时候会完成工作.不要采取错误的方式,没有个人:)

2> Howard May..：

---

以下链接提供有关WSDL与REST的有用信息,包括优点和缺点

关键点有几点

1)SOAP是为分布式计算环境设计的,其中REST是为点对点环境设计的.

2)WADL可用于定义REST服务的接口.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

---

REST是为分布式系统设计的:"[...]分布式超媒体系统的代表性状态转移(REST)架构风格[...]"(Fielding,2000)https://www.ics.uci.edu/~守备/酒吧/论文/ rest_arch_style.htm

3> John Saunder..：

---

关于WSDL(意为"SOAP")是"重量级".重要的是怎么样？如果工具集为您做了所有"繁重的工作",那为什么重要？

我从未需要使用复杂的REST API.当我这样做时,我希望我希望得到一个WSDL,我的工具很乐意转换成一组代理类,所以我可以调用看似方法的东西.相反,我怀疑为了使用一个非平凡的基于REST的API,有必要手动编写大量"轻量级"代码.

即使这一切都已完成,您仍然会将人类可读的文档翻译成代码,并伴随着人类错误阅读的伴随风险.由于WSDL是一种机器可读的服务描述,因此"读错"要困难得多.

---

请注意:自从这篇文章以来,我有机会使用中等复杂的REST服务.事实上,我确实希望获得WSDL或等价物,而且我确实必须手工编写大量代码.事实上,开发时间的很大一部分用于删除所有"手动"调用不同服务操作的代码的代码重复.

---

@kekoav:我回应罗米亚斯说他认为"轻量级"是关于性能的.我觉得任何有这种感觉的人都应该支持.另外,如果不进行测量,我不会假设性能更好,而且我不会测量,例如,事务与无事务,或WS-Security与HTTPS.建议对证据进行验证并不是火焰诱饵.

---

重量级并不是贬义,我只是说SOAP给了你很多,而且性能和复杂性都有所提高.在拳击比赛中,重量级比轻量级可能造成的伤害更大,但轻量级可以在不需要重量级时完成任务.此外,像WS-Security或Transactions这样的额外"东西"引入了REST根本没有的额外复杂性.

---

"用数字支持" - 经典的火焰棒.我是两者的粉丝,但两者都不是万能的.

4> sfitts..：

---

这可能真的属于上面几篇文章中的评论,但我还没有代表这样做,所以这里.

我认为有趣的是,SOAP和REST经常引用的许多优点和缺点(IMO)与这两种技术的实际值或限制几乎没有关系.可能被引用最多的REST专家认为它是"轻量级"或者往往更"人类可读".在某种程度上,这确实是正确的,REST确实具有较低的进入门槛 - 所需的结构比SOAP要少(虽然我同意那些说好的工具在很大程度上是答案的人 - 太糟糕了,SOAP工具很多非常可怕).

然而,除了初始入门成本之外,我认为REST印象来自请求URL的形式和大多数REST服务交换的数据的复杂性.REST倾向于鼓励更简单,更易读的请求URL,并且数据也更容易消化.但是,REST在多大程度上固有,以及它们在多大程度上仅仅是偶然的.更简单的URL结构是体系结构的直接结果 - 但它同样可以很好地应用于基于SOAP的服务.更难以消化的数据更可能是由于缺乏任何已定义的结构.这意味着您最好保持数据格式简单,或者您将要从事大量工作.因此,SOAP的附加结构应该是一个好处,实际上可以实现草率设计,然后将草率设计用作对技术的挖掘.

因此,为了在计算机系统之间交换结构化数据,我不确定REST本质上比SOAP更好(反之亦然),它们只是不同.我认为REST与SOAP之间的比较与动态与静态类型的比较是一个很好的.在动态语言倾向于遇到麻烦的地方是长期维护和维护系统(长期来说,我不是说一年或两年,我说的是5或10).看看REST是否会遇到同样的挑战会很有趣.我倾向于认为如果我构建一个分布式的信息处理系统,我会倾向于将SOAP作为通信机制(也是因为它提供了传输和应用协议分层以及它提供的灵活性,如上所述).

在其他地方虽然REST似乎更合适.客户端与其服务器之间的AJAX(无论有效负载)是一个主要的例子.我不太关心这种连接的寿命,易用性和灵活性是最重要的.同样,如果我需要快速访问某些外部服务,我认为我不会关心交互的可维护性(再次,我认为这是REST最终会花费我更多的成本,单向或者另一个),那么我可能会选择REST,这样我就能快速进出.

无论如何,它们都是可行的技术,并且取决于您想要为给定应用程序做出哪些权衡,它们可以很好地为您服务(或者很差).

5> troelskn..：

---

REST不是协议; 这是一种建筑风格.或者如果你想要的范例.这意味着SOAP更加宽松.对于基本的CRUD,您可以依赖标准协议,例如Atompub,但对于大多数服务,您将拥有更多的命令.

作为消费者,SOAP可能是一种祝福或诅咒,具体取决于语言支持.由于SOAP在严格类型的系统上进行了非常模型化,因此它最适用于静态类型语言.对于动态语言来说,它很容易变得狡猾和多余.此外,客户端库支持在Java和.NET世界之外并不是那么好