SOAP与REST（差异）

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

  1. REST更具动态性，无需创建和更新UDDI（通用描述、发现和集成）。

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

但是SOAP更加标准化（例如：安全性）。

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

1143466 次浏览
小开

REST vsSOAP是<强>不的正确问题。

REST，不像SOAP是<强>不协议。

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

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

@Abdulaziz的问题确实说明了REST和HTTP经常同时使用的事实。这主要是由于HTTP的简单性及其对RESTful原则的非常自然的映射。

REST基本原则

客户端-服务器通信

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

无国籍

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

可缓存

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

统一接口

所有组件都必须通过一个统一的接口进行交互。因为所有组件的交互都通过这个接口进行，所以与不同服务的交互非常简单。接口是一样的！这也意味着可以单独进行实现更改。这种更改不会影响基本的组件交互，因为统一接口总是不变的。一个缺点是你坚持使用接口。如果可以通过更改接口为特定服务提供优化，那么你就不走运了，因为REST禁止这样做。然而，从好的方面来看，REST是针对网络优化的，因此通过HTTP的REST令人难以置信地流行！

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

请参阅此博客帖子 onREST设计原则，了解有关REST和上述项目符号的更多详细信息。

编辑：根据评论更新内容

小开
最佳答案

不幸的是，围绕REST有很多虚假信息和误解。不仅您的问题和回复@cmd反映了这些，而且大多数问题和答案都与Stack Overflow上的主题相关。

SOAP和REST不能直接比较，因为前者是一种协议（或者至少试图成为），而后者是一种架构风格。这可能是围绕它的混淆的根源之一，因为人们倾向于将REST称为任何不是SOAP的HTTP API。

稍微推动一下并试图建立一个比较，SOAP和REST之间的主要区别在于客户端和服务器实现之间的耦合程度。SOAP客户端就像一个自定义桌面应用程序一样工作，与服务器紧密耦合。客户端和服务器之间有一个严格的契约，如果任何一方改变了什么，一切都将被打破。你需要在任何改变之后不断更新，但更容易确定契约是否被遵守。

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

我认为这些是理解REST的关键点，以及它与SOAP的区别：

最后一点怎么强调都不为过。如果您的客户端从留档中的模板构建URI，而没有在资源表示中获取链接，那就不是REST。REST的作者Roy Fielding在这篇博文中明确表示：REST API必须是超文本驱动的。

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

最后，REST并不适合所有人，一个证明就是大多数人如何用他们错误地称为REST的HTTP API很好地解决他们的问题，并且永远不会冒险超越它。REST有时很难做，尤其是在开始的时候，但随着时间的推移，服务器端更容易进化，以及客户端对变化的弹性，它是值得的。如果你需要快速轻松地完成某件事，不要费心把REST做好。这可能不是你想要的。如果你需要一些必须在线几年甚至几十年的东西，那么REST适合你。

小开

SOAP（简单对象访问协议）和REST（代表国家转移）都很漂亮。所以我不是在比较它们。相反，我试图描绘一幅图，当我更喜欢使用REST和SOAP时。

什么是有效载荷？

当数据通过互联网发送时，传输的每个单元都包括标头信息和正在发送的实际数据。标头标识数据包的来源和目的地，而实际数据被称为有效载荷。一般来说，有效负载是代表应用程序携带的数据和目的系统接收的数据。

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

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

<name>Arin</name>

或 

"name": "Arin"

我知道你的答案将是第二个，尽管两者都代表相同的信息，第二个在成本方面更便宜。

所以我想说，在网络上以JSON格式发送数据比以XML格式发送数据更便宜。

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

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

真的！怎么会？

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

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

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

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

正如我在上面的第0段中已经提到的，所以在这些话上再深入一点。

当我们谈论基于HTTP的REST时，所有应用于HTTP的安全措施都是继承的，这被称为传输级安全，它仅在它在电线里面时保护消息，但是一旦你在另一边传递它，你就不知道它必须经历多少阶段才能到达数据将被处理的真正点。当然，所有这些阶段都可以使用与HTTP不同的东西。所以休息并不完全安全，对吧？

但是SOAP支持ssl就像REST一样，增加了一些企业安全功能。WS-Security提供了创建消息到它的消费的保护。因此，对于传输级别的安全性，我们发现的任何漏洞都可以使用WS-Security来防止。

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

但是SOAP对短寿命事务的基于ACID的事务管理和长时间运行事务的基于补偿的事务管理都有全面的支持。它还支持跨分布式资源的两阶段提交。

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

这是“JavaEE 6教程”，他们说当满足以下条件时，RESTful设计可能是合适的。看看吧。

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

小开

REST（RE演示S tateT ransfer）
RE表示S个对象的状态是T转移是REST，即我们不发送对象，我们发送对象的状态。REST是一种架构风格。它没有像SOAP那样定义那么多标准。REST用于通过Internet公开公共API（即Facebook API、Google Maps API）来处理对数据的CRUD操作。REST专注于通过单个一致的接口访问命名资源。

SOAP（SimpleObject一个ccessPro协议）
SOAP带来了自己的协议，并专注于将应用程序逻辑（而不是数据）公开为服务。SOAP公开操作。SOAP专注于访问命名操作，每个操作实现一些业务逻辑。虽然SOAP通常被称为web服务，但这是误称。SOAP与Web几乎没有任何关系。REST基于URI和HTTP提供真正的Web服务。

为什么休息？

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

为什么是肥皂？

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

在此处输入图片描述

数据来源1
来源2

小开

恕我直言，你不能比较SOAP和REST，因为它们是两个不同的东西。

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

SOAP定义了基于XML的消息格式，支持Web服务的应用程序使用该格式通过Internet相互通信。为了做到这一点，应用程序需要事先了解消息契约、数据类型等。

REST表示来自URL的服务器的状态（作为资源）。它是无状态的，客户端不应该有超越超媒体理解的与服务器交互的先验知识。

小开

增加：

++在接近REST时经常犯的一个错误是将其视为“带有URL的Web服务”-将REST视为另一种远程过程调用（RPC）机制，如SOAP，但通过普通HTTP URL调用并且没有SOAP的庞大XML命名空间。

++相反，REST与RPC几乎没有关系。RPC是面向服务的，专注于动作和动词，而REST是面向资源的，强调组成应用程序的事物和名词。

小开

这些答案中的很多完全忘记了提到超媒体控制（HATEOAS），这是REST的基础。其他一些人提到了它，但并没有真正解释得那么好。

这篇文章应该解释概念之间的区别，而不必涉及特定SOAP功能的杂草。

小开

在许多答案中已经涵盖的许多其他答案中，我要强调SOAP能够定义合约、定义支持的操作、复杂类型等的WSDL。SOAP面向操作，而REST面向资源。就我个人而言，我会选择SOAP用于内部企业应用程序之间的复杂接口，而REST用于与外部世界的公共、更简单、无状态的接口。

在此处输入图片描述

小开

首先：正式地，正确的问题是web services + WSDL + SOAP vsREST。

因为，尽管网络服务是在松散的意义上使用的，但当使用HTTP协议传输数据而不是网页时，正式是该想法的一种非常具体的形式。根据定义，REST不是“Web服务”。

然而，在实践中，每个人都忽略了这一点，所以让我们也忽略它

已经有了技术上的答案，所以我将尝试提供一些直觉。

假设你想调用远程计算机中的一个函数，该函数用其他编程语言实现（通常称为远程过程调用/RPC）。假设该函数可以在编写它的人提供的特定URL上找到。你必须（以某种方式）向其发送消息，并获得一些响应。因此，有两个主要问题需要考虑。

  • 您应该发送的消息的格式是什么
  • 信息应该如何来回传递

对于第一个问题，官方定义是WSDL。这是一个XML文件，它以详细和严格的格式描述了什么是参数、它们的类型、名称、默认值、要调用的函数的名称等。一个示例WSDL在这里表明该文件是人类可读的（但不容易）。

对于第二个问题，有各种答案。然而，实践中唯一使用的是SOAP。它的主要思想是：将之前的XML（实际消息）包装成另一个XML（包含编码信息和其他有用的东西），并通过HTTP发送。自总有一具身体以来，HTTP的POST方法用于发送消息。

整个方法的主要思想是你将URL映射到函数，即一个行动。因此，如果您在某个服务器中有一个客户列表，并且您想查看/更新/删除一个，您必须有3个URL：

  • myapp/read-customer并在消息正文中传递要读取的客户的id。
  • myapp/update-customer并在主体中，传递客户的id，以及新数据
  • myapp/delete-customer和主体中的id

REST方法看待事物的方式不同。URL不应该代表操作，而是一件事（在REST术语中称为资源）。由于HTTP协议（我们已经在使用）支持动词，使用这些动词来指定哪些动作对事物执行。

因此，使用REST方法，可以在URLmyapp/customers/12上找到客户编号12。要查看客户数据，请使用GET请求点击URL。要删除它，请使用相同 URL和DELETE动词。要更新它，请使用再一次，同样的 URL和POST动词，以及请求正文中的新内容。

有关服务必须满足的要求才能被视为真正的RESTful的更多详细信息，请参阅理查森成熟度模型。本文给出了示例，更重要的是，解释了为什么（所谓的）SOAP服务是0级REST服务（尽管，0级意味着对该模型的低遵从性，它并不令人反感，并且在许多情况下仍然有用）。

小开

什么是REST

REST代表代表性状态传输，它实际上是一种用于创建Web API的架构风格，它将所有内容（数据或功能）视为资源。它期望；通过URI公开资源并以多种格式响应，以及以无状态方式表示资源状态的传输。这里我谈论两件事：

  1. 无状态方式：由HTTP提供。
  2. 状态的代表性转移：例如，如果我们要添加一个员工。在我们的系统中，它处于HTTP的POST状态，之后它将处于HTTP的GET状态，PUT和DELETE同样。

REST可以使用SOAP Web服务，因为它是一个概念，可以使用任何协议，如HTTP，SOAP.SOAP使用服务接口来公开业务逻辑。REST使用URI来公开业务逻辑。

没有HATEOAS，REST就不是REST。这意味着客户端只知道切入点URI，资源应该返回客户端应该遵循的链接。那些花哨的留档生成器为你在REST API中可以做的一切提供URI模式，完全没有抓住重点。它们不仅记录了应该遵循标准的东西，而且当你这样做时，你将客户端耦合到API演变的某个特定时刻，API上的任何更改都必须记录和应用，否则它会崩溃。

HATEOAS，Hypermedia As The Engine Of Application State的缩写，是REST应用程序架构的约束，使其有别于大多数其他网络应用程序架构。原理是客户端完全通过应用程序服务器动态提供的超媒体与网络应用程序交互。除了对超媒体的一般理解之外，REST客户端不需要关于如何与任何特定应用程序或服务器交互的先验知识。相比之下，在一些面向服务的架构（SOA）中，客户端和服务器通过通过留档或接口描述语言（IDL）共享的固定接口进行交互。

参考文献1参考文献2

小开

虽然SOAP和REST在HTTP协议上有相似之处，但SOAP是一组比REST更严格的消息传递模式。SOAP中的规则是相关的，因为没有它们我们就无法实现任何程度的标准化。REST不需要作为架构风格进行处理，并且本质上更通用。本着信息交换的精神，SOAP和REST都依赖于每个人都决定遵守的既定法律。SOAP与REST的选择取决于您使用的编程语言、您使用的环境和规范。

小开

要回答这个问题，了解分布式应用程序架构的演变很有用，从简单的分层架构，到基于对象和服务，再到基于资源，现在我们甚至有基于事件的架构。大多数大型系统使用风格的组合。

第一个分布式应用程序具有分层架构。我假设这里的每个人都知道什么是层。这些结构组织整齐，可以是堆栈或循环结构。努力维护单向数据流。

基于对象的体系结构是从分层体系结构演变而来的，遵循更松散的模型。在这里，每个组件都是一个对象（通常称为分布式对象）。对象使用类似于远程过程调用的机制相互交互——当客户端绑定到分布式对象时，它会将对象接口的实现加载到其地址空间中。RPC存根可以列表请求和接收响应。同样，服务器上的对象接口也是RPC风格的存根。这些基于对象的系统的结构组织得不那么整齐，它看起来更像一个对象图。

分布式对象的接口隐藏了它的实现。与分层组件一样，如果接口定义明确，内部实现可以更改，甚至完全替换。基于对象的体系结构为封装服务提供了基础。服务由自包含的实体提供，尽管在内部它可以使用其他服务。逐渐地，基于对象的体系结构演变为面向服务的体系结构（SOA）。 


使用SOA，分布式应用程序由服务组成。这些服务可以跨管理域提供-它们可以跨Web提供（即云提供商提供的存储服务）。

随着Web服务变得流行，越来越多的应用程序开始使用它们，服务组合（组合服务以形成新服务）变得更加重要。SOA的问题之一是集成不同的服务可能变得极其复杂。


虽然SOAP是一种协议，但它的使用意味着一种面向服务的体系结构。SOAP试图为服务提供一个标准，从而使它们可以组合并易于集成。

基于资源的架构是解决SOA集成问题的另一种方法。这个想法是将分布式系统视为由组件单独管理的巨大资源集合。这导致了RESTful架构的发展。RESTful服务的一个特点是无状态执行。这与服务器维护状态的SOA不同。

那么……面向服务的体系结构（包括使用SOAP的体系结构）提供的特定于服务的接口与基于资源的体系结构（如REST）相比如何？



虽然REST很简单，但它并没有为复杂的通信方案提供简单的接口。例如，如果你被要求使用事务REST是不合适的，最好将复杂的状态保持封装在服务器上，而不是让客户端管理事务。但是在许多情况下，RESTful架构中资源的正交使用大大简化了服务的集成，否则意味着服务接口的爆炸式增长。另一个权衡是基于资源的架构将更多的复杂性放在客户端上，增加了网络上的流量，而基于服务的架构增加了服务器的复杂性，增加了内存和CPU资源的税收。

有些人还提到了常见的HTTP服务或其他不满足RESTful架构或SOAP要求的服务。这些也可以分为基于服务的或基于资源的。这些具有更易于实现的优点。只有当您知道您的服务永远不需要跨管理域集成时，您才会使用这种方法，因为这不会尝试修复出现的集成问题。

这些类型的基于HTTP的服务，尤其是伪RESTful服务仍然是最常见的类型。实现SOAP很复杂，只应该在你真正需要它的时候使用——即你需要一个容易跨域集成的服务，并且你希望它有一个服务接口。仍然有需要这一点的情况。真正的RESTful服务也很难实现，尽管没有SOAP那么难。

小开

RESTAPI

RESTful API是最著名的API类型。REST代表再现状态传输。

REST API是遵循标准化原则、属性和约束的API。

您可以使用HTTP谓词访问REST API中的资源。

REST API在简单的请求/响应系统上运行。您可以使用以下HTTP方法发送请求：

  • get
  • POST
  • 把
  • 补丁
  • 删除
  • 跟踪
  • 选项
  • CONNECT
  • HEAD

以下是最常见的HTTP动词

  • 读取存量数据
  • POST（创建新的响应或数据）
  • PATCH（更新数据）
  • DELETE（删除数据）

客户端可以使用HTTP动词后跟端点发出请求。

端点（或路由）是您请求的URL。路径决定您请求的资源。

当您向端点发送请求时，它会响应相关数据，通常格式为JSON、XML、纯文本、图像、超文本标记语言等。

REST API还可以设计为具有返回不同类型数据的许多不同端点。使用REST API访问多个端点需要各种API调用。

实际的RESTful API遵循以下五个约束：

  1. 客户端-服务器架构
    客户端在没有第三方解释的情况下从服务器请求数据。

  2. 无国籍状态
    无状态意味着每个HTTP请求都完全独立地发生。每个请求都包含为请求提供服务所需的信息。服务器从不依赖以前请求中的信息。没有状态。

  3. 缓存
    响应可以显式或隐式地定义为可缓存或不可缓存，以提高可伸缩性和性能。例如，启用GET请求的缓存可以提高资源数据请求的响应时间。

  4. 分层
    API架构的不同层应该协同工作，创建一个易于更新或调整的可扩展系统。

  5. 统一接口
    客户端和服务器之间的通信必须使用独立于两者的标准化语言进行。这提高了可扩展性和灵活性。

REST API非常适合需要

  • 灵活
  • 可扩展
  • 快速

SOAPAPI

SOAP是帮助引入API广泛使用的必要协议。

SOAP是简单对象访问协议的首字母缩写。

SOAP是一种标准化协议，它依赖于XML来发出请求和接收响应。

尽管SOAP基于XML，但SOAP协议仍在广泛使用。

SOAP API使数据作为服务可用，通常在执行涉及多个API调用或以安全性为主要考虑因素的应用程序的事务时使用。

SOAP最初于1998年为Microsoft开发，旨在提供一种标准机制来集成Internet上的服务，而不管操作系统、对象模型或编程语言如何。

SOAP中的“S”代表简单，这是有充分理由的——SOAP可以以较低的复杂性使用，因为它在应用层中需要较少的编码来处理事务、安全性和其他功能。

SOAP有三个主要特性：

  1. SOAP API的可扩展性
    SOAP允许引入更强大功能的扩展，例如Windows Server安全性、寻址等。

  2. SOAP API的中立性
    SOAP能够在多种协议上运行，如UDP、JMS、SMTP、TCP和HTTP.can。

  3. SOAP API的独立性
    SOAP API响应纯粹基于XML。因此SOAP API独立于平台和语言。

开发人员继续讨论使用SOAP和REST的利弊。最适合您的项目的将是与您的需求一致的项目。

  • SOAP API仍然是优先考虑安全性的企业实体和政府组织的首选，尽管REST在很大程度上主导了Web应用程序。

  • SOAP比REST更安全，因为它使用WS-Security和安全套接字层进行传输

  • SOAP还具有更出色的事务可靠性，这是SOAP在历史上一直受到银行业和其他大型实体青睐的另一个原因。


提交答案