it-swarm.cn

SOAP 要么 REST 用于Web服务?

REST是一种更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题 - 也就是说,在某些领域比另一个稍微好一点,等等?

Bounty-Edit:

现在,差不多三年后,我想再次提出这个问题 - 提供奖励以鼓励深入回答。我特别感谢有关这些概念及其与PHP-universe和现代高端Web应用程序的关系的信息。

376
user13276

当我在Hewlett-Packard工作时,我从原始规范中构建了第一个SOAP服务器之一,包括代码生成和WSDL生成。我建议不要使用SOAP。

首字母缩略词“SOAP”是谎言。它不是简单的,它不是面向对象的,它没有定义Access规则。可以说,这是一项议定书。这是Don Box有史以来最糟糕的规格,这是一个非常壮举,因为他是犯下“COM”的人。

SOAP中没有任何用处,无法使用REST进行传输,JSON,XML甚至纯文本进行数据表示。对于传输安全性,您可以使用https。对于身份验证,基本身份验证。对于会话,有cookie。 REST版本将更简单,更清晰,运行更快,并且使用更少的带宽。

XML-RPC明确定义了请求,响应和错误协议,并且大多数语言都有很好的库。但是,XML比许多任务所需的重。

557
mdhughes

REST是一种体系结构,SOAP是一种协议。

这是第一个问题。

您可以在SOAP应用程序中发送REST envelope。

SOAP本身实际上非常基本和简单,它的WSS- *标准使其非常复杂。

如果您的消费者是其他应用程序和其他服务器,那么今天对SOAP协议有很多支持,移动数据的基础知识实际上是现代IDE中的鼠标单击。

如果您的消费者更可能是RIA或Ajax客户端,那么您可能需要比SOAP更简单的东西,并且更需要客户端(尤其是JSON)。

通过HTTP发送的JSON数据包不一定是REST体系结构,它只是URL的消息。一切都完全可行,但REST成语有关键组件。然而,很容易混淆两者。但仅仅因为你在谈论HTTP请求并不一定意味着你有一个REST架构。你可以拥有一个没有HTTP的REST应用程序(介意,这很少见)。

因此,如果您的服务器和消费者对SOAP“感到满意”,SOAP和WSS堆栈可以很好地为您服务。如果您正在做更多临时性的事情并希望更好地与Web浏览器进行交互,那么基于HTTP的一些较轻的协议也可以很好地工作。

197
Will Hartung

REST是与SOAP完全不同的范例。可以在这里找到关于REST的好读物: 我如何解释REST给我的妻子

如果你没有时间阅读它,这里是简短的版本:REST通过专注于“名词”是一种范式转换,并限制你可以应用于那些“动词”的数量名词。唯一允许的动词是“get”,“put”,“post”和“delete”。这与SOAP不同,其中许多不同的动词可以应用于许多不同的名词(即许多不同的功能)。

对于REST,四个动词映射到相应的HTTP请求,而名词由URL标识。这使得状态管理比SOAP更加透明,SOAP通常不清楚服务器上的状态和客户端上的状态。

在实践中虽然大部分都失败了,REST通常只是指在 _ json _ 中返回结果的简单HTTP请求,而SOAP是一个更复杂的API,通过传递XML进行通信。两者都有它们的优点和缺点,但我发现根据我的经验REST通常是更好的选择,因为你很少需要从SOAP获得的全部功能。

102
toluju

2012年快速下降问题:

REST非常适合的区域是:

  • 有限的带宽和资源。 记住返回结构实际上是任何格式(开发人员定义)。另外,可以使用任何浏览器,因为REST方法使用标准的GET,PUT,POST和DELETE动词。同样,请记住REST也可以使用大多数现代浏览器目前支持的XMLHttpRequest对象,这增加了AJAX的额外奖励。

  • 完全无状态的操作。 如果需要继续操作,那么REST不是最好的方法,SOAP可能更适合它。但是,如果您需要无状态CRUD(创建,读取,更新和删除)操作,那么REST就是它。

  • 缓存情况。 如果由于REST方法的完全无状态操作而可以缓存信息,这是完美的。这涵盖了上述三个中的许多解决方案。

那我为什么还要考虑SOAP呢?同样,SOAP相当成熟且定义明确,并且带有完整的规范。 REST方法只是一种方法,并且对于开发是开放的,所以如果你有以下那么SOAP是一个很好的解决方案:

  • 异步处理和调用。 如果您的应用程序需要有保证的可靠性和安全性,那么SOAP 1.2提供了额外的标准来确保这种类型的操作。像WSRM - WS-Reliable Messaging这样的东西。

  • 正式合同。 如果双方(提供者和消费者)必须就交换格式达成一致,那么SOAP 1.2给出了此类交互的严格规范。

  • 有状态的操作。 如果应用程序需要上下文信息和会话状态管理,则SOAP 1.2在WS *结构中具有附加规范以支持这些内容(安全性,事务,协调等)。相比之下,REST方法将使开发人员构建这个自定义管道。

http://www.infoq.com/articles/rest-soap-when-to-use-each

59
PmanAce

_ soap _ 目前具有更好工具的优势,它们将为服务层生成许多样板代码,并从任何给定的WSDL生成客户端。

_ rest _ 更简单,因此可以更容易维护,是Web架构的核心,允许更好的协议可见性,并且已被证明可以按照WWW本身的大小进行扩展。有些框架可以帮助你构建REST服务,比如Ruby on Rails,有些甚至可以帮助你编写客户端,比如ADO.NET Data Services。但在大多数情况下,缺乏工具支持。

44
Mark Cidade

SOAP从工具角度来看很有用,因为WSDL很容易被工具使用。因此,您可以使用您喜欢的语言为您生成Web服务客户端。

REST可以很好地与AJAX网页配合使用。如果您保持简单的请求,您可以直接从您的JavaScript进行服务调用,这非常方便。尽量避免在响应XML中使用任何名称空间,我已经看到浏览器会阻塞这些名称空间。所以,xsi:type可能不适合你,没有过于复杂的XML Schema。

REST往往也有更好的性能。生成REST响应的代码的CPU要求往往低于SOAP框架所展示的。而且,如果您在服务器端排列了XML生成器,则可以有效地将XML流式传输到客户端。所以,想象一下你正在读取数据库游标行。在读取行时,将其格式化为XML元素,然后将其直接写入服务使用者。这样,在开始编写XML输出之前,您不必收集内存中的所有数据库行 - 您可以同时读取和写入。查看新颖的模板引擎或XSLT,以使流程适用于REST。

另一方面,SOAP倾向于由工具生成的服务生成为一个大blob,然后才写入。这不是一个绝对的事实,请注意,有一些方法可以从SOAP中获取流特性,例如使用附件。

我的决策过程如下:如果我希望我的服务能够被消费者轻松加工,我写的消息将是中小型(10MB或更少),我不介意烧掉一些额外的CPU在服务器上循环,我使用SOAP。如果我需要在Web浏览器上提供AJAX,或者我需要流式传输,或者我的响应很大,我就去REST了。

最后,围绕SOAP建立了许多很好的标准,比如WS-Security和获取有状态的Web服务,如果你使用正确的工具,你可以插入它们。这种东西真的有所作为,可以帮助你满足一些毛茸茸的要求。

40
Dave Woldrich

我知道这是一个老问题,但我必须发布我的答案 - 也许有人会觉得它很有用。我无法相信有多少人推荐REST而不是SOAP。我只能假设这些人不是开发人员,或者从未实际实现任何合理大小的REST服务。实现REST服务比实现SOAP服务需要更长的时间。最后,它也变得更加混乱。以下是我选择SOAP 99%的时间的原因:

1)实现REST服务比实现SOAP服务花费的时间长得多。所有现代语言/框架/平台都存在用于读取WSDL并输出代理类和客户端的工具。实现REST服务是手工完成的 - 通过阅读文档得到这个。此外,在实现这两个服务时,您必须“猜测”管道中的内容,因为没有真正的架构或参考文档。

2)为什么要编写一个返回XML的REST服务?唯一的区别是,使用REST你不知道每个元素/属性所代表的类型 - 你可以自己实现它,并希望有一天字符串不会出现在你的字段中思想永远是一个整体。 SOAP使用WSDL定义数据结构,因此这是一个明智的选择。

3)我听说过使用SOAP你有SOAP Envelope的“开销”。在这个时代,我们真的需要担心少数几个字节吗?

4)我听说过使用REST你可以将URL弹出到浏览器中并查看数据。当然,如果你的REST服务使用简单认证或没有认证。例如,Netflix服务使用OAuth,它要求您在提交请求之前对事物进行签名和编码。

5)为什么我们需要每个资源的“可读”URL?如果我们使用工具来实现服务,我们真的关心实际的URL吗?

需要我继续吗?

29
Josh M.

我编写的大多数应用程序是服务器端C#或Java,或WinForms或WPF中的桌面应用程序。这些应用程序往往需要比REST所提供的更丰富的服务API。另外,我不想花费超过几分钟的时间来创建我的Web服务客户端。 WSDL处理客户端生成工具允许我实现我的客户端并继续增加业务价值。

现在,如果我正在为某些javascript ajax调用显式编写Web服务,那么它可能在REST中;只是为了了解客户端技术并利用JSON。在我看来,从javascript使用的Web服务API可能不应该非常复杂,因为这种类型的复杂性似乎更好地处理服务器端。

话虽如此,javascript还有一些SOAP个客户端;我知道jQuery有一个。因此,SOAP 能够 从javascript利用;只是不如返回JSON字符串的REST服务那么好。因此,如果我有一个我想要足够复杂的Web服务,它对于任意数量的客户端技术和用途都是灵活的,那么我将使用SOAP。

19
Travis Heseman

我建议你首先使用REST - 如果你正在使用Java查看JAX-RS和 Jersey 实现。 REST在许多语言中更加简单易学。

正如其他人在这个帖子中所说的那样,SOAP的问题是当其他WS- *规范出现时它的复杂性,如果你误入了WSDL,XSD,SOAP的错误部分,就会出现无数的互操作问题。 WS-Addressing等.

判断REST v SOAP辩论的最好方法是在互联网上看 - 几乎所有网络空间中的大玩家,谷歌,亚马逊,ebay,Twitter等 - 倾向于使用和优先于SOAP的RESTful API。

使用REST的另一种Nice方法是,您可以在Web应用程序和REST前端之间重用大量代码和基础结构。例如使用JAX-RS和隐式视图等框架渲染HTML与XML与资源的JSON通常相当容易 - 而且使用Web浏览器轻松使用RESTful资源

17
James Strachan

我确定Don Box创建SOAP作为一个笑话 - '看你 可以 通过网络调用RPC方法',今天当他意识到它变成了一个臃肿的网络标准噩梦时呻吟: - )

REST很好,很简单,在任何地方实现(比标准更“标准”)快速简便。使用REST。

16
gbjbaanb

我认为两者都有自己的位置。在我看来:

_ soap _ :遗留/关键系统与Web/Web服务系统之间的集成的更好选择,在基础层上,WS- *有意义(安全性,策略等)。

RESTful :使用公共API在网页顶层(VIEW,即javascripts调用URI)上进行网站集成的更好选择。

15
irobson

没有提到的一件事是SOAP信封可以包含标题和正文部分。这使您可以使用XML的完整表现力来发送和接收带外信息。据我所知,REST限制你使用HTTP标头和结果代码。

(otoh,您可以使用带有REST服务的cookie来发送“标题”类型的带外数据吗?)

13
John Saunders

不要忽视XML-RPC。如果您只是在轻量级解决方案之后,那么对于一个可以在几页文本中定义并以少量代码实现的协议,可以说很多。 XML-RPC已存在多年,但已经过时了一段时间 - 但极简主义的吸引力似乎给了它最近的复兴。

10
Cruachan

它很细致。

如果您需要让其他系统与您的服务接口,那么很多客户都会对SOAP感到满意,因为您拥有合同,WSDL和SOAP标准的“验证”层。

对于调用系统的日常系统,我认为SOAP在简单的HTML调用时会产生很多不必要的开销。

9
cynicalman

我正在看同样的事情,我认为, 它们是针对不同问题的不同工具

简单对象访问协议(SOAP)标准是定义消息体系结构和消息格式的XML语言,由Web服务使用,它包含操作的描述。 WSDL是一种基于XML的语言,用于描述Web服务以及如何访问它们。将运行在SMTP,HTTP,FTP等上。需要中间件支持,定义良好的机制来定义WSDL + XSD等服务,WS-Policy SOAP将返回基于XML的数据SOAP提供标准安全性和可靠性

代表性状态转移(RESTful)Web服务。它们是第二代Web服务。 RESTful Web服务,通​​过HTTP进行通信而不是基于SOAP的服务,并且不需要XML消息或WSDL服务API定义。 for REST不需要中间件只需要HTTP支持.WADL Standard,REST可以返回XML,纯文本,JSON,HTML等

许多类型的客户端更容易使用RESTful Web服务,同时使服务器端能够发展和扩展。客户可以选择使用服务的部分或全部方面,并将其与其他基于Web的服务混搭。

  1. REST使用标准HTTP,因此创建客户端,开发API非常简单
  2. REST允许许多不同的数据格式,如XML,纯文本,JSON,HTML,其中SOAP仅允许XML。
  3. REST具有更好的性能和可伸缩性。
  4. 休息并且可以缓存而SOAP不能
  5. 内置错误处理SOAP没有错误处理
  6. REST特别有用PDA和其他移动设备。

REST是服务易于与现有网站集成。

SOAP具有一组协议,这些协议提供安全性和可靠性标准,并与其他符合WS的客户端和服务器进行互操作。 SOAP Web服务(例如JAX-WS)在处理异步处理和调用时非常有用。

对于复杂API的SOAP将更有用。

9
kapil das

REST是Roy Fielding发明的一种架构,在他的论文中描述 建筑风格和基于网络的软件架构设计 。 Roy也是 _ http _ - 定义通过万维网传输文档的协议的主要作者。 HTTP是一种RESTful协议。当开发人员谈论“使用REST Web服务”时,说“使用HTTP”可能更准确。

SOAP是一种基于XML的协议,它在HTTP请求/响应中进行隧道传输,因此即使您使用SOAP,也使用REST。关于SOAP是否为基本HTTP添加任何重要功能存在争议。

在创作Web服务之前,我建议学习HTTP。您可以使用规范中已定义的功能来实现您的要求,因此不需要其他协议。

8
Chris Broski

我正在看同样的问题。在我看来,实际REST快速简单,适用于轻量级调用和响应,非常适合调试(比将URL抽入浏览器并查看响应更好)。

然而,REST似乎倒下的地方与它不是标准的事实有关(尽管它由标准组成)。大多数编程库都有一种检查WSDL的方法,以自动生成使用基于SOAP的服务所需的客户端代码。到目前为止,基于REST的Web服务似乎是一种编写接口以匹配可能的调用的更独特的方法。制作手动http请求然后解析响应。这本身就很危险。

SOAP的优点在于,一旦发布了WSDL,那么业务'可以构建他们的逻辑aorund,设置契约对接口的任何更改都将改变wsdl。没有任何空间可供使用。您可以根据该WSDL验证所有请求。但是,由于WSDL没有正确描述REST服务,因此您没有明确的方式来同意通信接口。

从商业角度来看,这似乎使得沟通对解释和变革持开放态度,这似乎是一个坏主意。

这个主题中的顶部'答案'似乎说SOAP代表面向对象的简单访问协议,但是在维基上看,O意味着对象不是面向对象的。他们是不同的东西。

我知道这篇文章很老,但我想我应该回答我自己的发现。

7
Exitos

这是一个很好的问题......我不想让你误入歧途,所以我会像你一样对别人的答案持开放态度。对我来说,它实际上取决于开销成本以及API的用途。我更喜欢在创建客户端软件时使用Web服务,但我不喜欢SOAP的重量。我相信,REST的重量较轻,但我不喜欢从客户的角度来看它的工作量差不多。

我很好奇别人的想法。

6
cranley

这个播客 找出来。如果你想在不听的情况下知道答案,那么OK,它的REST。但我真的建议听。

6
Mark Beckwith

我的一般规则是,如果您希望浏览器Web客户端直接连接到服务,那么您应该使用REST。如果要在后端服务之间传递结构化数据,请使用SOAP。

SOAP有时候很难设置,对于简单的Web客户端和服务器数据交换来说往往有点过分。不幸的是,我见过(并从中学到的)大多数简单的编程示例在某种程度上重新强化了这种看法。

也就是说,当您开始将多个SOAP服务组合在一起作为由数据工作流(思考企业软件)驱动的更大流程的一部分时,SOAP真的很闪耀。这是许多SOAP编程示例未能传达的内容,因为执行某些操作的简单SOAP操作(如获取股票的价格)通常过于复杂,因为除非在提供机器可读API的背景下呈现,否则详细说明具有输入和输出的设定数据格式的特定功能,而这些数据格式又由更大的过程编写。

这在某种程度上是令人遗憾的,因为它确实给SOAP一个坏名声,因为很难显示SOAP的优点而不在最终产品的完整背景下展示它用来。

6
Rick Sarvas

在“PHP-universe”的意义上PHP支持任何高级SOAP很糟糕。一旦跨越基本需求,您将最终使用 http://wso2.com/products/web-services-framework/php/ ,甚至无需内置WS-Security或WS-RM支持。

SOAP信封创建我觉得PHP很乱,它创建命名空间的方式,xsd:nil,xsd:anytype和旧式的soap服务使用SOAP编码(天知道有什么不同)在_ [SOAP消息。

通过坚持REST避免所有这些混乱,REST自从WWW开始以来我们一直没有使用它。我们才意识到这个 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm paper出来后它展示了我们如何使用HTTP功能来实现RESTFul服务。 HTTP本身就是REST,这并不意味着只使用HTTP使您的服务RESTFul。

SOAP忽略了HTTP的核心功能,并将HTTP视为一种传输协议,因此它在理论上是独立于传输协议的(实际上,如果不是谷歌的话,你是否听说过SOAP Action标题? !)。

随着JSON适应性的增加和HTML5与javascript的成熟REST与JSON已成为处理服务的最常见方式。如果需要,还可以将JSON Schema与WADL一起用于企业级解决方案(仍处于早期阶段)。

对REST和JSON的PHP支持肯定比现有的内置SOAP支持更好。

在SOA,WOA,ROA中添加更多BUZZ字

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

顺便说一下,我喜欢SOAP尤其是对于WS-Security规范,这是一个很好的规范,如果有人在企业JSON适应中思考,肯定需要为JSON提供类似的东西,比如字段级加密等。

4
shivaspk

_ soap _ 体现了面向服务的Web服务方法 - 其中方法(或动词)是您与服务交互的主要方式。 _ rest _ 采用面向资源的方法,其中对象(或名词)占据中心位置。

4
Vibha Sanskrityayan

一个快速点 - 传输协议和编排;

出于速度,可靠性和安全性原因,我使用SOAP over TCP,包括编排的机器到机器服务(ESB)和外部服务。更改服务定义,业务流程从WSDL更改中引发错误,并且它立即显而易见,可以重建/部署。

不确定你可以用REST做同样的事情 - 我等待纠正或当然!使用REST,更改服务定义 - 在返回400(或其他任何内容)之前一无所知。

3
BlueChippy

如果您正在寻找不同系统和语言之间的互操作性,我肯定会选择REST。例如,我在尝试让SOAP在.NET和Java之间工作时遇到了很多问题。

2
neu242

我创建了一个基准,用于查找哪些更快!我看到这个结果:

1000个请求:

  • REST花了3秒钟
  • SOAP花了7秒钟

10,000个请求:

  • REST花了33秒
  • SOAP耗时69秒

对于1,000,000个请求:

  • REST花了62秒
  • SOAP耗时114秒
2
Sonador

一个老问题,但今天仍然相关....由于企业领域的许多开发人员仍在使用它。

我的工作涉及设计和开发物联网(物联网)解决方案。其中包括为与云通信的小型嵌入式设备开发代码。

很明显REST现在被广泛接受和使用,并且几乎是网络的事实标准,甚至微软也在整个Azure中都包含REST支持。如果我需要依赖SOAP我无法做我需要做的事情,因为对于小型嵌入式设备来说太大,太笨重和烦人。

REST简单,干净,小巧。使其成为小型嵌入式设备的理想选择当我与一位向我发送WSDL的Web开发人员合作时,我总是尖叫。因为我将不得不开始一个关于为什么这不起作用以及他们为什么要学习REST的教育活动。

0
Remixed123

1.根据我的经验。我会说REST为您提供了访问已构建的URL的选项。 eg-> google中的单词搜索。该URL可以用作REST的Web服务。在SOAP中,您可以创建自己的Web服务并通过SOAP client访问它。

  1. REST支持文本,JSON,XML格式。因此,两个应用程序之间的通信更加通用。虽然SOAP仅支持XML格式的消息通信。
0
Shalini Baranwal