题 SOAP与REST(差异)


我读过有关SOAP和REST作为Web服务通信协议之间差异的文章,但我认为REST优于SOAP的最大优势是:

  1. REST更具动态性,无需创建和更新UDDI。

  2. REST不限于XML格式。 REST Web服务可以发送 纯文本,JSON和XML。

但SOAP更标准化(Ex;安全性)。

那么,我在这些方面是否正确?


990
2017-11-09 23:11


起源


有一个字母比喻,我很喜欢SOAP vs REST, 使用SOAP,你正在使用信封,使用REST,它是一张明信片,显然SOAP有一些额外的开销:更多的带宽(更多的纸张),双方的额外工作(包装和解包)。但这并不意味着REST不像SOAP那么安全,因为你可以使用HTTPS(把它想象为用只会说外语的人取代邮递员) - watashiSHUN
spf13.com/post/soap-vs-rest - Rigel
nishantshukla001webservices.blogspot.in/2015/09/... - Nico
“在很多方面,基于HTTP的万维网本身可以被视为基于REST的架构。” - Abhijeet
按照 理查森成熟度模型 将REST方法的主要元素分解为三个步骤,SOAP是Level 0 REST。 - Sampada


答案:


不幸的是,围绕REST存在很多错误信息和误解。不仅是你的问题和 回答@cmd 反映这些,但大多数问题和答案与Stack Overflow上的主题相关。

SOAP和REST无法直接比较,因为第一个是协议(或至少是尝试),第二个是架构风格。这可能是其中混淆的原因之一,因为人们倾向于将REST称为非SOAP的任何HTTP API。

推动一些事情并尝试建立比较,SOAP和REST之间的主要区别在于客户端和服务器实现之间的耦合程度。 SOAP客户端的工作方式类似于自定义桌面应用程序,与服务器紧密耦合。客户端和服务器之间存在严格的合同,如果任何一方发生任何变化,预计一切都会中断。您需要在任何更改后不断更新,但更容易确定是否遵循合同。

REST客户端更像是一个浏览器。它是一个通用客户端,知道如何使用协议和标准化方法,并且应用程序必须适合它。您不会通过创建额外的方法来违反协议标准,您可以利用标准方法并在媒体类型上使用它们创建操作。如果做得好,那么耦合就会减少,并且可以更优雅地处理更改。除了入口点和媒体类型之外,客户端应该输入没有API知识的REST服务。在SOAP中,客户端需要先前了解它将要使用的所有内容,否则它甚至不会开始交互。此外,REST客户端可以通过服务器本身提供的按需代码进行扩展,经典示例是用于驱动与客户端上的另一个服务的交互的JavaScript代码。

我认为这些是了解REST的关键点,以及它与SOAP的区别:

  • REST与协议无关。它没有耦合到HTTP。非常类似于您可以在网站上关注ftp链接,REST应用程序可以使用任何具有标准化URI方案的协议。

  • REST不是CRUD到HTTP方法的映射。读 这个 回答对此的详细解释。

  • REST与您正在使用的部分一样标准化。 HTTP中的安全性和身份验证是标准化的,因此这是您在通过HTTP进行REST时使用的内容。

  • 没有REST就不是REST 超媒体 和 HATEOAS。这意味着客户端只知道入口点URI,并且资源应该返回客户端应该遵循的链接。那些为REST API中可以执行的操作提供URI模式的精美文档生成器完全忽略了这一点。它们不仅记录了应该遵循标准的内容,而且当您这样做时,您将客户端耦合到API发展过程中的某个特定时刻,并且必须记录和应用API的任何更改,或者它会破裂。

  • REST是Web本身的架构风格。当您输入Stack Overflow时,您知道用户,问题和答案是什么,您知道媒体类型,并且网站为您提供了指向它们的链接。 REST API也必须这样做。如果我们按照人们认为应该完成REST的方式设计Web,而不是让主页上有问题和答案的链接,我们会有一个静态文档解释为了查看问题,你必须获取URI stackoverflow.com/questions/<id>,用Question.id替换id并将其粘贴到浏览器上。这是无稽之谈,但这就是许多人认为REST的含义。

最后一点不够强调。如果您的客户正在从文档中的模板构建URI而不是在资源表示中获取链接,那么这不是REST。 REST的作者Roy Fielding在这篇博客文章中明确表示: REST API必须是超文本驱动的

考虑到上述情况,您将意识到虽然REST可能不限于XML,但要使用任何其他格式正确执行,您必须设计并标准化链接的某些格式。超链接是XML的标准配置,但不是JSON中的标准配置。有JSON的草案标准,比如 HAL

最后,REST并不适合所有人,并且证明这一点就是大多数人使用他们错误地称为REST的HTTP API很好地解决他们的问题并且从不冒险。 REST有时很难做到,特别是在开始阶段,但随着时间的推移,它可以在服务器端更容易进化,并且客户端能够适应变化。如果您需要快速轻松地完成某项工作,请不要为正确的REST而烦恼。这可能不是你想要的。如果您需要一些必须在线保持数年甚至数十年的东西,那么REST就适合您。


1464
2017-11-10 00:45



任何一个都没问题。问题是用户如何获取URL,而不是他们如何使用URL。他们应该从其他文档中的链接获取搜索URL,而不是从文档中获取。该文档可以解释如何使用搜索资源。 - Pedro Werneck
检查URI模板, tools.ietf.org/html/rfc6570。 - Pedro Werneck
@CristiPotlog我从未说过SOAP依赖于任何特定的协议,我只是强调REST不是如何。你发送的第二个链接说REST需要HTTP,这是错误的。 - Pedro Werneck
让我们再说一遍:HATEOAS是一个 约束 如果你想打电话给你的API Restful! - Orestis
@SachinKainth有一个答案 这里。您可以将CRUD操作映射到HTTP方法,但这不是REST,因为它不是RFC中记录的那些方法的预期语义。 - Pedro Werneck


REST VS SOAP 是  正确的问题。

REST不像 SOAP 是  协议。

REST 是一个 建筑风格 和a 设计 用于基于网络的软件架构。

REST 概念被称为资源。资源的表示必须是无状态的。它通过某种媒体类型表示。媒体类型的一些示例包括 XMLJSON,和 RDF。资源由组件操纵。组件通过标准统一接口请求和操作资源。在HTTP的情况下,该接口由标准HTTP操作组成,例如 GETPUTPOSTDELETE

@ Abdulaziz的问题确实说明了这一事实 REST 和 HTTP 通常串联使用。这主要是由于HTTP的简单性以及它与RESTful原则的非常自然的映射。

基本REST原则

客户端 - 服务器通信

客户端 - 服务器架构具有非常明显的关注点分离。所有以RESTful样式构建的应用程序原则上也必须是客户端 - 服务器。

无状态

每个客户端对服务器的请求都要求其状态完全表示。服务器必须能够完全理解客户端请求,而无需使用任何服务器上下文或服务器会话状态。因此,所有州必须保留在客户端上。

可缓存

可以使用高速缓存约束,从而使响应数据能够被标记为可高速缓存或不可高速缓存。标记为可缓存的任何数据都可以重用作对同一后续请求的响应。

统一界面

所有组件必须通过单一的统一接口进行交互。由于所有组件交互都通过此接口进行,因此与不同服务的交互非常简单。界面是一样的!这也意味着可以单独进行实现更改。这种变化不会影响基本的组件交互,因为统一的接口总是不变的。一个缺点是您遇到了界面。如果可以通过更改界面为特定服务提供优化,那么由于REST禁止此操作,您将失去运气。然而,从好的方面来看,REST针对Web进行了优化,因此REST在HTTP上非常受欢迎!

上述概念表示REST的定义特征,并将REST架构与Web服务等其他架构区分开来。值得注意的是,REST服务是一种Web服务,但Web服务不一定是REST服务。

看到这个博客 岗位 上 REST设计原则 有关详细信息 休息 以及上述子弹。

编辑: 根据评论更新内容


246
2017-11-09 23:19



REST没有一组预定义的CRUD操作操作。盲目地将HTTP方法映射到CRUD操作是围绕REST最常见的误解之一。 HTTP方法具有非常明确的行为,与CRUD无关,而REST不与HTTP耦合。例如,你可以在ftp上拥有一个REST API,只有RETR和STOR。 - Pedro Werneck
另外,“REST服务是幂等的”是什么意思?据我所知,你有一些HTTP方法,默认情况下是幂等的,如果你的服务中的特定操作需要幂等性,你应该使用它们,但是说服务是幂等的没有意义。该服务可以具有可以以幂等或非幂等方式实现的动作的资源。 - Pedro Werneck
@cmd:请删除第四点 - “RESTful架构可能使用HTTP或SOAP作为底层通信协议”。这是你传达的错误信息。 - Bruce_Wayne


肥皂 (简单对象访问协议) 和休息 (代表国家转让)两者都很美。所以我不是在比较它们。相反,当我更喜欢使用REST和SOAP时,我试图描绘图片。

什么是有效载荷? 

当通过因特网发送数据时,发送的每个单元包括头信息和发送的实际数据。标头标识数据包的源和目标, 而实际数据则称为有效载荷。通常,有效载荷是代表应用程序携带的数据和目标系统接收的数据。

现在,例如,我必须发送一个 电报 我们都知道电报的费用取决于一些字眼。

那么请告诉我下面提到的这两条消息,哪一条发送更便宜?

<name>Arin</name>

要么

"name": "Arin"

我知道你的答案将是第二个,虽然两个代表相同的消息,第二个是成本更便宜。

所以我想说, 以JSON格式通过网络发送数据比以有关负载的XML格式发送数据要便宜

这是REST over SOAP的第一个好处或优点。 SOAP只支持XML,但REST支持不同的格式,如文本,JSON,XML等。我们已经知道,如果我们使用Json,那么我们肯定会在有效载荷方面做得更好。

现在,SOAP支持唯一的XML, 但它也有其优点。 

真!怎么样?

SOAP以三种方式依赖于XML 信封 - 定义消息中的内容以及如何处理消息。

一组数据类型的编码规则,最后是过程调用和响应的布局。

此信封通过传输(HTTP / HTTPS)发送,并执行RPC(远程过程调用),并返回包含XML格式文档中信息的信封。

重点是 SOAP的优点之一 就是使用了 “通用”运输 但 REST使用HTTP / HTTPS。 SOAP几乎可以使用任何传输来发送请求,但REST不能。所以在这里我们获得了使用SOAP的优势。

正如我在上面提到的那样 “REST使用HTTP / HTTPS”,所以对这些话更深入一点。

当我们讨论基于HTTP的REST时,所有应用HTTP的安全措施都是继承的,这就是所谓的 运输级安全 它只保护邮件 它在电线内部 但是一旦你在另一边交付它,你就不知道在到达处理数据的真实点之前需要经过多少个阶段。当然,所有这些阶段都可以使用与HTTP不同的东西。所以休息并不完全安全,对吧?

但是SOAP 支持SSL 就像REST一样 它还支持WS-Security 这增加了一些企业安全功能。 WS-Security提供保护 为消费创造消息。因此,对于传输级安全性,我们发现可以使用WS-Security阻止任何漏洞。

除此之外,作为 REST受其HTTP协议的限制 因此,它的事务支持既不符合ACID,也不能跨分布式跨国资源提供两阶段提交。

但是SOAP对这两者都有全面的支持 基于ACID的事务管理 用于长期交易的短期交易和基于补偿的交易管理。它也支持 跨分布式资源的两阶段提交

我没有得出任何结论,但我更喜欢基于SOAP的Web服务,而安全性,事务等是主要关注点。

这是他们所说的“Java EE 6教程” 当满足以下条件时,RESTful设计可能是合适的。看一看。

希望你喜欢阅读我的答案。


189
2018-06-14 19:48



[解决了]php999.blogspot.in/2015/06/soap-vs-rest-web-services.html - indian
很好的答案,但记住REST可以使用任何传输协议。例如,它可以使用FTP。 - Bhargav Nanekalva
谁说REST不能使用SSL? - Osama Aftab
要引用关于XML数据大小的观点,在启用压缩时,XML非常小。 - GaTechThomas
关于有效载荷大小的观点应该被删除,它是JSON和XML之间的这种一维比较,并且只能在严重优化的设置中进行检测。 - ThomasRS


休息回覆表象的 小号泰特 Ť转让(BOT))
REST是一种架构风格。它没有定义像SOAP这么多的标准。 REST用于通过Internet公开公共API(即Facebook API,Google Maps API)以处理数据的CRUD操作。 REST专注于通过单个一致的接口访问命名资源。

肥皂小号imple Øbject 一个CCESS Protocol)
SOAP带来了自己的协议,并专注于将应用程序逻辑(而非数据)作为服务公开。 SOAP公开了操作。 SOAP专注于访问命名操作,每个操作都实现一些业务逻辑。虽然SOAP通常被称为 网页服务 这是用词不当。 SOAP与Web有很小的关系。 REST提供了真实的 网页服务 基于URI和HTTP。

为何选择REST? 

  • 由于REST使用标准HTTP,因此它在任何方面都要简单得多。
  • REST更容易实现,需要更少的带宽和资源。
  • REST允许许多不同的数据格式,而SOAP只允许XML。
  • 由于支持JSON,REST允许更好地支持浏览器客户端。
  • REST具有更好的性能和可伸缩性。可以缓存REST读取,不能缓存基于SOAP的读取。
  • 如果安全不是主要问题,我们的资源有限。或者我们想要创建一个公开其他开发人员可以轻松使用的API然后我们应该使用REST。
  • 如果我们需要无状态CRUD操作,那么请使用REST。
  • REST通常用于社交媒体,网络聊天,移动服务和Google Maps等公共API。
  • RESTful服务返回相同资源的各种MediaType,具体取决于请求标头参数“Accept”as application/xml 要么 application/json 用于POST和 /user/1234.json 或者GET /user/1234.xml 为GET。
  • REST服务旨在由客户端应用程序调用,而不是直接由最终用户调用。
  • ST 在REST中来自 小号泰特 Ť转让(BOT)。您转移状态而不是让服务器存储它,这使REST服务可以扩展。

为何选择SOAP? 

  • SOAP实现起来不是很容易,需要更多的带宽和资源。
  • 与REST相比,SOAP消息请求的处理速度较慢,并且它不使用Web缓存机制。
  • WS-Security的: 虽然SOAP支持SSL(就像REST一样),但它也支持WS-Security,它增加了一些企业安全功能。
  • WS-AtomicTransaction的: 需要通过服务进行ACID事务,您将需要SOAP。
  • WS-ReliableMessaging的: 如果您的应用程序需要异步处理并保证可靠性和安全性。 Rest没有标准的消息传递系统,并期望客户通过重试来处理通信故障。
  • 如果安全性是一个主要问题并且资源不受限制,那么我们应该使用SOAP Web服务。就像我们正在为支付网关,金融和电信相关工作创建Web服务一样,我们应该使用SOAP,因为这里需要高安全性。

enter image description here

来源1
源2


82
2017-12-08 23:38



REST动词/方法与CRUD方法没有1比1的关系,尽管它可以帮助我们开始理解REST风格。 - Santiago Martí Olbrich
REST不支持SSL?休息的统一资源网址不能以https://开头? - Mou


其他答案给出了广泛的明显差异,并详细解释了很多。因此,我会远离那些答案,并问你是否仍然感到困惑,如果是这样,那么你可能想看看这个简单的类比。 enter image description here


60
2018-06-23 05:19



精湛的画报代表.. - Hari krishna
这很有用 工作解释 最新的,现实的实现,但它在理论上是不正确的。 REST是一种架构风格,SOAP是一种协议。 REST不必使用HTTP。 - bendodge
伟大的视觉呈现,我喜欢他们如何简化它。您从哪本书中获取此图片表示?我很想读它。 - Amir De
同意@bendodge。此外,SOAP也不必使用HTTP: stackoverflow.com/questions/4540301/...。换句话说,你可以用任何其他动物取代那匹马,例如哈士奇。但100年前像马力这样的HTTP,可能是最常见的交通方式。另外我认为这完全给出了SOAP的图片(一旦你允许不同的动物),运载代表了WSDL的约束,但它没有图形化地表示REST的哲学,超出了它的一些数据交换手段的事实。 - Colm Bhandal


两者之间的决定将是您设计Web服务的首选,因此了解两者的优缺点非常重要。在两种哲学之间有时激烈的争论中,将现实与修辞分开也很重要。

REST基础知识

  • REST中的所有内容都被视为资源。
  • 每个资源都由URI标识。
  • 使用统一的接口。使用POST,GET,PUT,DELETE操作处理资源,这些操作类似于创建,读取,更新和删除(CRUD)操作。
  • 无国籍。每个请求都是一个独立的请求。从客户端到服务器的每个请求都必须包含理解请求所需的所有信息。
  • 通过表示进行通信。例如,XML,JSON RESTful Web服务。 RESTful Web服务基于HTTP方法和REST的概念。 RESTful Web服务通常定义服务的基URI;支持的MIME类型(XML,文本,JSON,用户定义,...)和支持的操作集(POST,GET,PUT,DELETE)。

SOAP基础知识

  • WSDL定义了客户端和服务之间的契约,并且本质上是静态的。
  • SOAP在HTTP或有时TCP / IP之上构建基于XML的协议。
  • SOAP描述了数据的功能和类型。
  • SOAP是XML-RPC的后继者,非常相似,但描述了一种标准的通信方式。
  • 有几种编程语言对SOAP有本机支持,您通常会将其作为Web服务URL提供,您可以在不需要特定代码的情况下调用其Web服务功能。
  • 发送的二进制数据必须首先编码为base64编码格式。
  • 有几个与之相关的协议和技术:WSDL,XSD,SOAP,WS-Addressing。

SOAP与REST?

SOAP的一个主要优点是您拥有WSDL服务描述。您几乎可以自动发现服务并从该服务描述生成可用的客户端代理(生成服务调用,方法所需的数据类型等)。请注意,对于版本2.0,WSDL支持所有HTTP谓词,并且也可以用于记录RESTful服务,但是为此目的,在WADL(Web应用程序描述语言)中有一个不太详细的替代方案。

使用RESTful服务,消息安全性由传输协议(HTTPS)提供,并且仅是点对点的。它没有标准的消息传递系统,并希望客户端通过重试来处理通信故障。 SOAP内置了成功/重试逻辑,即使通过SOAP中介提供端到端的可靠性。

RESTful API的一个主要优点是它可以灵活地进行数据表示,例如,您可以使用XML或JSON格式序列化数据。 RESTful API更清晰或更容易理解,因为它们添加了使用标准化URI的元素,并重视所使用的HTTP动词(即GET,POST,PUT和DELETE)。

RESTful服务也是轻量级的,即它们没有很多额外的XML标记。要调用RESTful API,您只需要一个浏览器或HTTP堆栈,几乎所有连接到网络的设备或机器都具有该功能。

REST的优点

  • 由于REST使用标准HTTP,因此几乎在所有方面都更简单。创建客户端,开发API,文档更容易理解,并且REST没有比SOAP更容易/更好的事情。
  • REST允许许多不同的数据格式,而SOAP只允许XML。虽然这看起来似乎增加了REST的复杂性,因为你需要处理多种格式,根据我的经验,这是非常有益的。 JSON通常更适合数据和解析更快。由于支持JSON,REST允许更好地支持浏览器客户端。
  • REST具有更好的性能和可伸缩性。 REST读取可以缓存;无法缓存基于SOAP的读取。
  • 没有昂贵的工具需要与Web服务交互
  • 较小的学习曲线
  • 高效(SOAP对所有消息使用XML,REST可以使用较小的消息格式)
  • 快速(无需大量处理)
  • 更接近设计理念中的其他Web技术

SOAP的优点

  • WS-Security的: 虽然SOAP支持SSL(就像REST一样),但它也支持WS-Security,它增加了一些企业安全功能。通过中介支持身份,而不仅仅是点对点(SSL)。它还提供数据完整性和数据隐私的标准实现。将其称为“企业”并不是说它更安全,它只是支持典型的互联网服务不需要的一些安全工具,事实上,它们仅在少数“企业”场景中需要。
  • WS-AtomicTransaction的: 需要通过服务进行ACID事务,您将需要SOAP。虽然REST支持事务,但它并不全面且不符合ACID。幸运的是,ACID交易几乎从未在互联网上有意义。 REST受HTTP本身的限制,它不能跨分布式事务资源提供两阶段提交,但SOAP可以。互联网应用程序不需要这种级别的事务可靠性,企业应用程序有时会这样做。
  • WS-ReliableMessaging的: Rest没有标准的消息传递系统,并期望客户通过重试来处理通信故障。 SOAP内置了成功/重试逻辑,即使通过SOAP中介提供端到端的可靠性。
  • 语言,平台和传输独立(REST需要使用HTTP)
  • 在分布式企业环境中运行良好(REST假定直接的点对点通信)
  • 标准化
  • 以WS标准的形式提供重要的预构建可扩展性
  • 内置错误处理
  • 与某些语言产品一起使用时的自动化

在哪里使用REST 

REST运行良好的领域是:

  • 有限的带宽和资源: 记住返回结构实际上是任何格式(开发人员定义)。此外,可以使用任何浏览器,因为REST方法使用标准的GET,PUT,POST和DELETE动词。同样,请记住,REST也可以使用大多数现代浏览器目前支持的XMLHttpRequest对象,这增加了AJAX的优势。
  • 无国籍行动: 如果需要继续操作,那么REST不是最好的方法,SOAP可能更适合它。但是,如果您需要无状态CRUD(创建,读取,更新和删除)操作,那么REST就是它。
  • 缓存情况: 如果由于REST方法的无状态操作而可以缓存信息,这是完美的。

在哪里使用SOAP

SOAP作为一个很好的解决方案的领域:

  • 异步处理和调用: 如果您的应用程序需要有保证的可靠性和安全性,那么SOAP 1.2提供了额外的标准来确保这种类型的操作。像WSRM - WS-Reliable Messaging之类的东西。
  • 正式合同: 如果双方(提供者和消费者)必须就交换格式达成一致,那么SOAP 1.2为这种类型的交互提供了严格的规范。
  • 有状态的操作: 如果应用程序需要上下文信息和会话状态管理,则SOAP 1.2在WS结构中具有附加规范以支持这些内容(安全性,事务,协调等)。相比之下,REST方法将使开发人员构建这种自定义管道。

43
2018-04-21 11:12



REST不仅限于HTTP,也不限于CRUD操作 - forresthopkinsa
写起来很容易理解。 - Lee


休息和肥皂之间的区别

肥皂

  1. SOAP是一种协议。
  2. SOAP代表简单对象访问协议。
  3. SOAP不能使用REST,因为它是一种协议。
  4. SOAP使用服务接口来公开业务逻辑。
  5. SOAP定义了严格遵循的标准。
  6. SOAP需要比REST更多的带宽和资源。
  7. SOAP定义了自己的安全性。
  8. SOAP仅允许XML数据格式。
  9. SOAP不如REST优先。

休息

  1. REST是一种架构风格。
  2. REST代表Representational State Transfer。
  3. REST可以使用SOAP Web服务,因为它是一个概念,可以使用任何协议,如HTTP,SOAP。
  4. REST使用URI来公开业务逻辑。
  5. REST没有定义太多像SOAP这样的标准。
  6. REST比SOAP需要更少的带宽和资源。
  7. RESTful Web服务从底层传输继承安全措施。
  8. REST允许不同的数据格式,如纯文本,HTML,XML,JSON等。
  9. REST比SOAP更受欢迎。

有关详细信息,请参阅 这里


29
2018-03-21 12:47





恕我直言,你无法比较SOAP和REST,它们是两个不同的东西。

肥皂是一个协议和 休息 是一种软件架构模式。互联网上有很多误解 SOAP与REST

肥皂 定义基于XML的消息格式,启用Web服务的应用程序通过Internet相互通信。为了做到这一点,应用程序需要事先了解消息契约,数据类型等。

休息 表示来自URL的服务器的状态(作为资源)。它是无状态的,除了对超媒体的理解之外,客户端不应该具有与服务器交互的先验知识。


12
2018-01-17 00:17





增加:

++在接近REST时经常犯的错误是将其视为“带URL的Web服务” - 将REST视为另一种远程过程调用(RPC)机制,如SOAP,但是通过纯HTTP URL调用而没有SOAP的大量XML命名空间。

++相反,REST与RPC几乎没有关系。虽然RPC是面向服务的,并且专注于动作和动词,但REST是面向资源的,强调构成应用程序的事物和名词。


5
2017-09-20 08:02