SOAP vs REST（差异）

我已经阅读了有关SOAP和REST作为Web服务通信协议之间差异的文章，但是我认为REST优于SOAP的最大优点是：

  1. REST更加dynamic，不需要创build和更新UDDI。

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

但是SOAP更加标准化（Ex;安全性）。

那么，我在这些方面是否正确？

不幸的是，REST有很多错误的信息和误解。 不仅你的问题和@cmd的答案反映了这些，而且大多数问题和答案都与Stack Overflow的主题相关。

SOAP和REST不能直接比较，因为第一个是协议（或者至less是试图），第二个是架构风格。 这可能是其中的一个混淆之处，因为人们倾向于将任何不是SOAP的HTTP API称为REST。

推动一点，试图build立一个比较，SOAP和REST的主要区别是客户端和服务器实现之间的耦合程度。 一个SOAP客户端就像一个自定义的桌面应用程序，紧密地连接到服务器。 客户端和服务器之间有一个严格的合同，如果任何一方改变了任何东西，一切都将被打破。 您需要在更改后不断更新，但更容易确定合同是否得到遵守。

REST客户端更像是一个浏览器。 这是一个通用的客户端，知道如何使用一个协议和标准化的方法，一个应用程序必须适应。 您不要通过创build额外的方法来违反协议标准，而是利用标准方法并在您的媒体types上使用标准方法创build操作。 如果做得对，那么耦合就less了，变化可以更优雅地处理。 除了入口点和媒体types之外，客户端应该input一个REST服务，不知道API。 在SOAP中，客户端需要以前的知识，甚至不会开始交互。 此外，REST客户端可以通过服务器本身提供的按需代码进行扩展，典型的例子是JavaScript代码，用于驱动与客户端上的另一个服务的交互。

我认为这些是了解REST是什么的关键，以及它与SOAP有什么不同：

  • REST是独立于协议的。 这不是耦合到HTTP。 就像你可以在一个网站上跟踪一个ftp链接一样，一个REST应用程序可以使用任何有一个标准URIscheme的协议。

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

  • REST与您使用的部件一样标准化。 HTTP中的安全性和身份validation是标准化的，所以这就是通过HTTP进行REST时所使用的。

  • 没有超媒体和HATEOAS， REST不是REST。 这意味着客户端只知道入口点URI，资源应该返回客户端应该遵循的链接。 那些为REST API中的所有function提供URI模式的特殊文档生成器完全没有考虑到这一点。 他们不仅logging应该遵循标准的东西，而且当你这样做的时候，你将客户联系到API发展的一个特定时刻，API的任何变化都必须被logging和应用，否则会中断。

  • REST是Web本身的架构风格。 当你input堆栈溢出时，你知道用户，问题和答案是什么，你知道媒体types，网站提供给你的链接。 REST API也必须这样做。 如果我们按照人们认为应该完成REST的方式来devise网页，那么我们就会有一个静态文档来解释，为了查看一个问题，您必须采用URI stackoverflow.com/questions/<id> ，将idreplace为Question.id并粘贴到您的浏览器上。 这是无稽之谈，但这就是很多人认为REST的原因。

最后一点不能被强调。 如果您的客户正在从文档中的模板构buildURI并且没有获取资源表示中的链接，那不是REST。 REST的作者Roy Fielding在这篇博文中明确表示： REST API必须是超文本驱动的 。

考虑到上述情况，您将意识到虽然REST可能不限于XML，但要正确使用任何其他格式，您必须为链接devise和标准化某些格式。 超链接在XML中是标准的，但不在JSON中。 有JSON的标准草案，像HAL 。

最后，REST并不适合所有人，而且大多数人通过HTTP API错误地解决了他们的问题，他们错误地称之为REST，而且从来没有冒险过。 有时REST很难做到，特别是在开始阶段，但随着时间的推移，服务器端的更容易的演变以及客户端对变化的适应能力将得到支持。 如果您需要快速而轻松地完成某些操作，请不要为获取正确的REST而烦恼。 这可能不是你在找什么。 如果你需要一些必须保持在线的东西，那么REST就是为你服务的。

REST vs SOAP 不是正确的问题。

与SOAP不同， REST 不是协议。

REST是基于networking的软件体系结构的体系结构风格和devise 。

REST概念被称为资源。 资源的表示必须是无状态的。 它通过一些媒体types来表示。 媒体types的一些例子包括XML ， JSON和RDF 。 资源由组件操纵。 组件通过标准的统一接口请求和操作资源。 在HTTP的情况下，这个接口由标准的HTTP操作组成，例如GET ， PUT ， POST ， DELETE 。

@阿卜杜勒阿齐兹的问题确实certificate了REST和HTTP经常被联合使用的事实。 这主要是由于HTTP的简单性以及对RESTful原则的非常自然的映射。

基本的REST原则

客户端 – 服务器通信

客户端 – 服务器体系结构具有非常明显的关注点。 所有以REST风格构build的应用程序原则上也必须是客户端服务器。

无状态

每个客户端对服务器的请求都要求其状态得到充分的表示。 服务器必须能够完全理解客户端请求，而不使用任何服务器上下文或服务器会话状态。 因此，所有国家都必须留在客户身上。

可caching

可以使用caching约束，从而使响应数据被标记为可caching或不可caching。 标记为可caching的任何数据可以被重新用作对相同的后续请求的响应。

统一的界面

所有组件必须通过一个统一的接口进行交互。 因为所有的组件交互都是通过这个接口进行的，所以与不同服务的交互非常简单 界面是一样的！ 这也意味着实施的变化可以孤立地进行。 这种变化不会影响基本的组件交互，因为统一的接口总是不变的。 一个缺点是你被卡在界面上。 如果通过更改界面可以为特定服务提供优化，那么REST禁止这样做是不可能的。 然而，好的一面是，REST针对networking进行了优化，因此REST over HTTP的受欢迎程度令人难以置信！

上述概念代表了REST的特性，并将REST架构与其他架构（如Web服务）区分开来。 请注意，REST服务是一项Web服务，但Web服务不一定是REST服务。

有关REST和上述项目符号的更多详细信息，请参阅RESTdevise原则的博客文章 。

编辑：根据评论更新内容

SOAP（ 简单对象访问协议 ）和REST（ 表示状态传输 ）都是以自己的方式很漂亮。 所以我没有比较他们，而是我试图描绘图片，当我更喜欢使用REST和SOAP时。

什么是有效载荷？

当通过因特网发送数据时，每个传送的单元包括标题信息和正在发送的实际数据。 报头标识数据包的来源和目的地， 而实际数据被称为有效载荷 。 通常，有效载荷是代表应用程序携带的数据以及目标系统接收的数据。

现在，例如，我必须发送一个电报 ，我们都知道电报的成本将取决于单词的数量。

那么告诉我下面提到的这两条消息，哪一条比较便宜？ 

 <name>Arin</name>

要么 

 "name": "Arin"

我知道你的答案是第二个，尽pipe代表相同的第二个消息在成本方面更便宜。

所以我想说的是， 通过JSON格式通过networking发送数据比以Xml格式发送有效载荷更便宜 。

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

现在，SOAP只支持XML， 但也有其自身的优势。

真！ 怎么样？

SOAP以三种方式依赖于XML Envelope – 它定义了消息中的内容以及如何处理它。

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

此信封通过传输（HTTP / HTTPS）发送，并执行RPC（远程过程调用），信封以XML格式的文档中的信息返回。

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

正如我在上面“REST使用HTTP / HTTPS”中已经提到的那样，所以对这些词汇进行更深入的研究。

当我们谈论REST over HTTP时，所有应用HTTP的安全措施都是inheritance的，这就是所谓的传输级安全性 ，它只在内部线路中保证消息的安全 ，但是一旦你把消息传递给另一方，在达到数据处理的真实点之前，需要经过多less个阶段。 当然，所有这些阶段都可以使用与HTTP不同的东西。 所以rest不是完全安全的，对吧？

但是SOAP像REST一样支持SSL ，另外它还支持添加一些企业安全function的WS-Security 。 WS-Security为消息的创build提供了保护。 所以对于传输层面的安全性，无论我们发现什么漏洞都可以使用WS-Security来阻止。

除此之外，由于REST受到HTTP协议的限制，因此事务支持既不兼容ACID，也不能跨分布式跨国资源提供两阶段提交。

但SOAP对短期交易的基于ACID的交易pipe理和长期交易的基于薪酬的交易pipe理提供了全面的支持。 它还支持跨分布式资源的两阶段提交 。

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

以下是他们所说的“Java EE 6教程”： 当符合以下条件时，REST风格的devise可能是合适的 。 看一看。

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

SOAP与REST Web服务

SOAP和REST Web服务之间有很多不同之处。 SOAP和REST之间的重要差异如下：

  1. SOAP是一个协议 。 REST是一种build筑风格 。
  2. SOAP代表简单对象访问协议 。 REST代表REpresentational State Transfer 。
  3. SOAP 不能使用REST，因为它是一个协议。 REST 可以使用SOAP Web服务，因为它是一个概念，可以使用任何协议，如HTTP，SOAP。
  4. SOAP 使用服务接口来公开业务逻辑 。 REST 使用URI来公开业务逻辑 。
  5. 在Java中， JAX-WS是用于SOAP Web服务的Java API。 在Java中， JAX-RS是用于REST风格的Web服务的Java API。
  6. SOAP 定义了严格遵循的标准 。 REST没有定义太多的SOAP标准。
  7. SOAP比REST 需要更多的带宽和资源。 REST比SOAP 需要更less的带宽和资源。
  8. SOAP 定义了自己的安全性 。 REST风格的Web服务从底层传输中inheritance安全措施 。
  9. SOAP只允许XML数据格式。 REST 允许不同的数据格式 ，如纯文本，HTML，XML，JSON等
  10. SOAP比REST 更不受欢迎。 REST比SOAP 更受欢迎。

REST （ RE演示文稿传输）
REST是一种build筑风格。 它没有定义像SOAP那么多的标准。 REST是通过互联网公开一个公开的API来处理数据的CRUD操作。 REST专注于通过一个一致的接口访问命名资源。

SOAP （实现O bject A ccess P协议）
SOAP带来了自己的协议，并将重点放在应用程序逻辑（而不是数据）作为服务。 SOAP公开操作。 SOAP专注于访问命名操作，每个操作都通过不同的接口实现一些业务逻辑。 虽然SOAP通常被称为Web服务，但这是一个误用。 如果与Web有任何关系，SOAP就很less了。 REST基于URI和HTTP提供真正的Web服务 。

为什么rest？

  • 由于REST使用标准的HTTP，所以在任何情况下都要简单得多。
  • REST允许许多不同的数据格式，因为SOAP只允许XML。
  • 由于支持JSON，REST可以更好地支持浏览器客户端。
  • REST具有更好的性能和可伸缩性。 REST读取可以被caching，基于SOAP的读取不能被caching。
  • 如果安全不是主要问题，我们资源有限。 或者我们想创build一个API，这个API将被其他开发人员公开使用，那么我们应该使用REST Web服务。
  • 如果我们需要无状态的CRUD操作。

为什么是SOAP？

  • WS-Security：虽然SOAP支持SSL（就像REST一样），但它也支持WS-Security，它增加了一些企业安全function。
  • WS-AtomicTransaction：需要一个服务的ACID事务，你将需要SOAP。
  • WS-ReliableMessaging：如果您的应用程序需要asynchronous处理并保证可靠性和安全性。 Rest没有标准的消息传递系统，希望客户通过重试来处理通信故障。
  • SOAP是高度安全的，因为它定义了自己的安全性。
  • 如果安全性是一个主要问题，资源不受限制，那么我们应该使用SOAP Web服务。 就像我们为银行相关的工作创build一个Web服务一样，那么我们应该使用SOAP，因为在这里需要高度的安全性。

在这里输入图像说明

来源1
源2

两者之间的决定将是您deviseWeb服务的首选，因此了解这两者的优缺点非常重要。 在两个哲学之间有时激烈的辩论中，把现实与修辞分开也是重要的。

REST基础

  • REST中的所有内容都被视为一种资源。
  • 每个资源都由URI标识。
  • 使用统一的接口。 POST，GET，PUT，DELETE操作处理资源，类似于Create，Read，Update和Delete（CRUD）操作。
  • 无国籍 每个请求都是一个独立的请求。 客户端到服务器的每个请求都必须包含理解请求所需的全部信息。
  • 通信是通过表示完成的。 例如XML，JSON RESTful Web服务RESTFul Web服务基于HTTP方法和REST的概念。 RESTFul Web服务通常定义服务的基本URI，受支持的MIMEtypes（XML，文本，JSON，用户定义的…）以及支持的操作集合（POST，GET，PUT，DELETE） 。

SOAP基础

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

SOAP与REST？

SOAP的一个主要好处是你有一个WSDL服务描述。 您几乎可以自动发现服务，并根据该服务描述（生成服务调用，方法的必要数据types等）生成可用的客户端代理。 请注意，在2.0版本中，WSDL支持所有的HTTP动词，并且可以用来为RESTful服务编写文档，但是WADL（Web应用程序描述语言）中有一个较为冗长的select。

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

RESTful API的一个主要优点是它对于数据表示很灵活，例如可以用XML或JSON格式序列化数据。 REST风格的API更清晰或易于理解，因为它们添加了使用标准化URI的元素，并重视所使用的HTTP动词（即GET，POST，PUT和DELETE）。

REST风格的服务也是轻量级的，也就是说他们没有太多额外的XML标记。 要调用RESTful API，您只需要一个浏览器或HTTP堆栈，几乎所有连接到networking的设备或机器都具有该function。

REST的优点

  • 由于REST使用标准的HTTP，所以在任何情况下都要简单得多。 创build客户端，开发API，文档更容易理解，而且REST不比SOAP更简单/更好。
  • REST允许许多不同的数据格式，因为SOAP只允许XML。 虽然这看起来似乎增加了REST的复杂性，因为您需要处理多种格式，但根据我的经验，这实际上是非常有益的。 JSON通常更适合数据并且parsing得更快。 由于支持JSON，REST可以更好地支持浏览器客户端。
  • REST具有更好的性能和可伸缩性。 REST读取可以被caching，基于SOAP的读取不能被caching。
  • 没有昂贵的工具需要与Web服务交互
  • 较小的学习曲线
  • 高效（SOAP使用所有消息的XML，REST可以使用更小的消息格式）
  • 快速（不需要广泛的处理）
  • 在devise理念上更接近其他Web技术

SOAP的优点

  • WS-Security：虽然SOAP支持SSL（就像REST一样），但它也支持WS-Security，它增加了一些企业安全function。 通过中介支持身份，而不仅仅是点对点（SSL）。 它还提供了数据完整性和数据隐私的标准实现。 称之为“企业”并不是说它更安全，它只是支持一些典型的互联网服务不需要的安全工具，实际上它们只是在less数“企业”情况下才需要的。
  • WS-AtomicTransaction：需要一个服务的ACID事务，你将需要SOAP。 虽然REST支持事务处理，但它并不全面，不符合ACID标准。 幸运的是，ACID交易在互联网上几乎没有任何意义。 REST受HTTP本身的限制，不能提供跨分布式事务资源的两阶段提交，但SOAP可以。 互联网应用程序通常不需要这种级别的事务可靠性，有时企业应用程序也可以。
  • WS-ReliableMessaging： Rest没有标准的消息传递系统，希望客户通过重试来处理通信故障。 SOAP内置成功/重试逻辑，甚至通过SOAP中介提供端到端的可靠性。
  • 语言，平台和传输独立（REST需要使用HTTP）
  • 在分布式企业环境中运行良好（REST假定直接点对点通信）
  • 标准化
  • 以WS标准的forms提供重要的预构build可扩展性
  • 内置error handling
  • 与某些语言产品一起使用时自动化

在哪里使用REST

REST工作得很好的领域是：

  • 有限的带宽和资源：记住，返回结构确实是任何格式（开发人员定义）。 另外，可以使用任何浏览器，因为REST方法使用标准的GET，PUT，POST和DELETE动词。 同样，请记住，REST还可以使用大多数现代浏览器支持的XMLHttpRequest对象，这增加了AJAX的额外好处。
  • 完全无状态的操作：如果操作需要继续，那么REST并不是最好的方法，SOAP可能更好。 但是，如果您需要无状态CRUD（创build，读取，更新和删除）操作，那么REST就是这样。
  • caching情况：如果由于REST方法的完全无状态操作而可以caching信息，这是完美的。

在哪里使用SOAP

SOAP作为一个很好的解决scheme的领域是：

  • asynchronous处理和调用：如果您的应用程序需要可靠性和安全性的保证，那么SOAP 1.2提供了额外的标准来确保这种types的操作。 比如WSRM – WS-Reliable Messaging。
  • 正式合同：如果双方（提供者和消费者）必须就交换格式达成一致，则SOAP 1.2给出了这种交互types的严格规范。
  • 有状态操作：如果应用程序需要上下文信息和会话状态pipe理，那么SOAP 1.2在WS结构中有附加的规范来支持这些事情（安全，事务，协调等）。 相对而言，REST方法将使开发人员构build这个定制pipe道。

你可能想看看这个简单的比喻来使事情更清楚。 在这里输入图像说明

rest和肥皂之间的区别

肥皂

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

rest

  1. REST是一种build筑风格。
  2. REST代表具象状态转移。
  3. REST可以使用SOAP Web服务，因为它是一个概念，可以使用任何协议，如HTTP，SOAP。
  4. REST使用URI来公开业务逻辑。
  5. REST没有定义太多的SOAP标准。
  6. REST比SOAP需要更less的带宽和资源。
  7. REST风格的Web服务从底层传输中inheritance安全措施。
  8. REST允许不同的数据格式，如纯文本，HTML，XML，JSON等
  9. REST比SOAP更受欢迎。

欲了解更多详情，请看这里

恕我直言，你不能比较那些是两个不同的东西的SOAP和REST。

SOAP是一种协议， REST是一种软件架构模式。 SOAP和REST在互联网上有很多误解。

SOAP定义了基于XML的消息格式，使得支持Web服务的应用程序可以通过互联网互相通信。 为了这样做，应用程序需要事先知道消息合约，数据types等。

REST代表一个服务器的状态（作为资源），它是无状态的，除了超媒体的理解之外，客户端不应该事先知道与服务器交互。

好吧，我看到很多新的Web服务是使用REST风格的架构而不是SOAP来实现的。 让我们退一步，解释一下REST是什么。

什么是REST Web服务

首字母缩写REST代表Representational State Transfer，这基本上意味着每个唯一的URL是某个对象的表示。 您可以使用HTTP GET获取该对象的内容，删除它，然后可以使用POST，PUT或DELETE修改对象（实际上大多数服务使用POST来实现此目的）。

谁在使用REST？

所有雅虎的networking服务都使用REST，包括Flickr，del.icio.us API使用它，pubsub，bloglines，technorati和eBay，Amazon都有REST和SOAP的Web服务。

谁在使用SOAP？

Google接口在实现其Web服务时使用SOAP是一致的，但使用XML-RPC的Blogger除外。 您也可以在许多企业软件中findSOAP Web服务。

REST vs SOAP

正如你可能已经注意到我所提到的那些使用REST API的公司已经很久没有出现，而且他们的API大部分都是在今年才出现的。 所以REST绝对是一种创buildWeb服务的stream行方式，如果创buildWeb服务可能是时髦的（让我们用肥皂洗脸，然后在疲倦的时候rest）。

REST Web服务的主要优点是：

  • 轻量级 – 不是很多额外的XML标记
  • 人类可读的结果
  • 易于构build – 无需工具包

SOAP也有一些优点：

  • 容易消耗 – 有时
  • 刚性型检查，坚持合同
  • 开发工具

对于消费Web服务，它有时候更容易折腾起来。 例如，Google的AdWordsnetworking服务真的很难使用（无论在CF中），它使用SOAP标头以及其他一些其他的东西，这使得它很难。 相反，亚马逊的REST Web服务有时可能很难parsing，因为它可以高度嵌套，结果模式可以根据您search的内容而有所不同。

您select哪种架构确保开发人员能够轻松访问它，并且logging良好。

希望这会帮助你:)

增加：

++接近REST时经常犯的一个错误就是将其视为“具有URL的Web服务” – 将REST视为另一个远程过程调用（RPC）机制，如SOAP，但是通过普通的HTTP URL调用，并且不使用SOAP安全XML名称空间。

++相反，REST与RPC没什么关系。 鉴于RPC是面向服务的，专注于动作和动词，REST是以资源为导向的，强调构成应用程序的事物和名词。

Interesting Posts

REST和WebServices之间的区别

JSON，REST，SOAP，WSDL和SOA：它们如何链接在一起

WCF – 检查正在发送/接收的消息？

在PHP SoapClient中禁用证书validation

Android，通过HTTP POST（SOAP）发送XML

具象状态转移（REST）和简单对象访问协议（SOAP）

为什么JSON使用XML（SOAP）如此简单易处理？

如何使用SoapClient类进行PHP SOAP调用

JAX-RS和JAX-WS有什么区别？

如何从PHP发布SOAP请求