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

有人能用简单的英语解释什么是REST和SOAP吗？以及Web服务是如何工作的？

283254 次浏览
小开

我认为这是我所能解释的最简单的。欢迎任何人纠正我或补充这一点。

SOAP是断开连接的系统（如通过Internet）用于交换信息/数据的消息格式。它与来回的XML消息有关。

Web服务传输或接收SOAP消息。它们的工作方式不同，具体取决于它们使用的语言。

小开

这两种方法都被许多大玩家使用。这是一个偏好的问题。我更喜欢REST，因为它更容易使用和理解。

简单对象访问协议（SOAP）：

  • SOAP在HTTP或有时TCP/IP之上构建XML协议。
  • SOAP描述函数和数据类型。
  • SOAP是XML-RPC的继承者，非常相似，但描述了一种标准的通信方式。
  • 一些编程语言对SOAP有原生支持，您通常会为它提供一个Web服务URL，并且您可以调用它的Web服务函数而无需特定代码。
  • 发送的二进制数据必须首先编码为诸如bas64编码的格式。
  • 有几个与之相关的协议和技术：WSDL、XSD、SOAP、WS寻址

具象状态转移（REST）：

  • REST不需要通过HTTP，但我下面的大部分观点都会有HTTP偏见。
  • REST是非常轻量级的，它说等一下，我们不需要SOAP创建的所有这些复杂性。
  • 通常使用普通的HTTP方法而不是描述一切的大XML格式。例如，要获取资源，您使用HTTP GET；要将资源放在服务器上，您使用HTTP PUT；要删除服务器上的资源，您使用HTTP DELETE。
  • REST非常简单，因为它使用HTTP GET、POST和PUT方法来更新服务器上的资源。
  • REST通常最好与面向资源的架构（ROA）一起使用。在这种思维模式下，一切都是资源，您将对这些资源进行操作。
  • 只要您的编程语言有一个HTTP库（大多数都有），您就可以非常轻松地使用REST HTTP协议。
  • 二进制数据或二进制资源可以简单地根据他们的请求交付。

有关于谷歌上REST与SOAP的无休止的辩论。

我最喜欢的是这个。 2013年11月27日更新：Paul Prescod的网站似乎已经离线，这篇文章不再可用，但可以在Wayback Machine或CiteSeerX的PDF上找到副本。

小开

我喜欢Brian R. Bondy的回答。我只是想补充一下，维基百科提供了对REST的清晰描述。这篇文章将其与SOAP区分开来。

REST是一种尽可能简单的状态信息交换。

SOAP是一种使用XML的消息协议。

许多人从SOAP转向REST的主要原因之一是与基于SOAP的Web服务相关的WS-*（称为WS spat）标准非常复杂。有关规范列表，请参阅wikipedia。这些规范中的每一个都非常复杂。

编辑：由于某种原因，链接无法正确显示。REST=http://en.wikipedia.org/wiki/REST

WS-*=http://en.wikipedia.org/wiki/WS-*

小开

SOAP和REST都指不同系统相互通信的方式。

REST使用类似于浏览器与Web服务器通信的技术来执行此操作：使用GET请求网页、在表单字段中发布等。

SOAP提供了类似的东西，但通过来回发送XML块来完成所有工作。SOAP的另一个关键组件是WSDL，它是一个描述支持哪些功能和数据元素的XML文档。WSDL可用于以编程方式“发现”支持哪些功能以及生成编程代码存根。

小开

SOAP的问题在于它与HTTP堆栈背后的理想相冲突。任何中间件都应该能够在不了解请求或响应内容的情况下处理HTTP请求，但是例如，常规的HTTP缓存服务器如果不知道SOAP内容的哪些部分需要缓存，就无法处理SOAP请求。SOAP只是使用HTTP作为自己通信协议的包装器，就像代理一样。

小开

关于SOAP和REST的简单解释

SOAP-“简单对象访问协议”

SOAP是一种通过Internet传输消息或少量信息的方法。SOAP消息以XML格式格式化，通常使用HTTP（超文本传输协议）发送。

REST-具象状态转移

Rest是一种在客户端和服务器之间发送和接收数据的简单方法，它没有定义很多标准。您可以以JSON、XML甚至纯文本的形式发送和接收数据。与SOAP相比，它的权重较轻。

输入图片描述

小开

这是你能找到的最简单的解释。

这篇文章以丈夫对妻子的叙述，丈夫用纯粹的外行术语向妻子解释REST。必须阅读！

我是怎么向我妻子解释休息的（原始链接）
我是怎么向我妻子解释休息的（2013-07-19工作链接）

小开

REST

我知道REST的主要思想非常简单。我们已经使用网络浏览器多年，我们已经看到了网站是多么容易，灵活，执行等。超文本标记语言网站使用超链接和表单作为用户交互的主要手段。他们的主要目标是让我们，客户端，只知道那些我们可以在当前状态下使用的链接。REST简单地说“为什么不使用相同的原则来驱动计算机而不是人类客户通过我们的应用程序？”将其与WWW基础设施的功能相结合，您将获得构建出色分布式应用程序的杀手级工具。

另一种可能的解释是对数学思维的人来说。每个应用程序基本上都是一个状态机，业务逻辑操作是状态转换。REST的思想是将每个转换映射到对资源的一些请求上，并为客户端提供代表当前状态下可用转换的链接。因此，它通过表示和链接对状态机进行建模。这就是为什么它被称为再现状态传输。

令人惊讶的是，所有的答案似乎都集中在消息格式或HTTP动词的使用上。事实上，消息格式根本不重要，REST可以使用任何一种，只要服务开发人员记录它。HTTP动词只能使服务成为CRUD服务，但还不是RESTful。真正将服务变成REST服务的是与数据一起嵌入到服务器响应中的超链接（又名超媒体控件），它们的数量必须足以让任何客户端从这些链接中选择下一步操作。

不幸的是，在Web上很难找到关于REST的正确信息，除了罗伊·菲尔丁的论文（他是REST的派生者）。我推荐《实践中的休息》一书，因为它提供了一个全面的分步教程，说明如何从SOAP发展到REST。

SOAP

这是RPC（远程过程调用）架构风格的可能形式之一。本质上，它只是一种允许客户端通过服务边界（网络、进程等）调用服务器方法的技术，就好像他们在调用本地方法一样。当然，它实际上在速度、可靠性等方面与调用本地方法不同，但想法就是这么简单。

比较

当将任何形式的RPC与REST进行比较时，传输协议、消息格式、xsd、wsdl等细节并不重要。主要的区别在于，RPC服务通过在RPC API中设计自己的应用程序协议，使用只有它知道的语义学来重塑自行车。因此，所有客户端在使用该服务之前都必须了解该协议，并且由于所有请求的专有语义学，无法构建像缓存这样的通用基础设施。此外，RPC API没有建议在当前状态下允许什么操作，这必须来自额外的留档。另一方面，REST意味着使用统一的接口来允许各种客户端对API语义学有一些理解，并使用超媒体控件（链接）来突出显示每个状态中的可用选项。因此，它允许缓存响应以扩展服务，并使正确的API使用易于发现，而无需额外的留档。

在某种程度上，SOAP（和任何其他RPC一样）是一种通过服务边界隧道的尝试，将连接媒体视为一个只能传输消息的黑匣子。REST是一个承认Web是一个巨大的分布式信息系统的决定，接受世界的现状，学会掌握它，而不是与它对抗。

当您同时控制服务器和客户端时，SOAP似乎非常适合内部网络API，而交互并不太复杂。开发人员使用它更自然。然而，对于许多独立方使用的公共API来说，它既复杂又大，REST应该更适合。但最后一个比较是非常模糊的。

更新

我的经验出乎意料地表明，REST开发比SOAP更难。至少对于. NET来说是这样。虽然有ASP.NETWeb API这样的优秀框架，但没有一种工具可以自动生成客户端代理。不像“添加Web服务参考”或“添加WCF服务参考”。必须手动编写所有序列化和服务查询代码。伙计，那是很多样板代码。我认为REST开发需要类似于WSDL的东西和每个开发平台的工具实现。事实上，似乎有一个很好的基础：WADL或WSDL2.0，但这两个标准似乎都没有得到很好的支持。

更新（2016年1月）

原来现在有一个各种各样的工具用于REST API定义。我的个人偏好目前是RAML。

Web服务如何工作

这是一个太宽泛的问题，因为它取决于特定Web服务中使用的架构和技术。但一般来说，Web服务只是Web中的一些应用程序，可以接受来自客户端的请求并返回响应。它暴露在Web上，因此它是一个web服务，并且通常24/7全天候可用，这就是为什么它是服务。当然，它为其客户端解决了一些问题（否则为什么会有人使用Web服务）。

小开

好吧，我将从第二个问题开始：什么是Web服务？，原因很明显。

WebServices本质上是公开某些功能或数据的逻辑片段（您可能模糊地将其称为一种方法）。客户端实现（从技术上讲，消费是这个词）只需要知道方法将接受哪些参数以及它将返回的数据类型（如果它确实接受的话）。

下面的Link以非常清晰的方式讲述了REST和SOAP。

REST与SOAP

如果您还想知道何时选择什么（REST或SOAP），那么就更有理由通过它了！

小开

REST是一种用于设计网络应用程序的架构风格。其思想是，与使用CORBA、RPC或SOAP等复杂机制在机器之间进行连接相比，使用简单的HTTP在机器之间进行调用。

小开

基于SOAP的Web服务 简而言之，基于SOAP的服务模型将世界视为一个由共同平等的对等方组成的生态系统，这些对等方不能相互控制，但必须通过遵守已发布的合同来共同工作。这是一个有效的 混乱的现实世界的模型，以及基于元数据的契约形成了SOAP服务接口。

我们仍然可以将SOAP与基于XML的远程过程调用相关联，但基于SOAP的Web服务技术已经成为一种灵活而强大的消息传递模型。

SOAP假设所有系统都是独立的，没有系统知道另一个系统的内部和内部功能。 此类系统最多能做的就是相互发送消息并希望它们会被执行。系统发布它们承诺遵守的合约，其他系统依赖这些合约与它们交换消息。

系统之间的契约统称为元数据，包括服务描述、支持的消息交换模式和管理服务质量的策略（服务可能 需要加密、可靠地传递等）服务描述反过来是系统将发送和接收的数据（消息文档）的详细规范。文档是 使用XML描述语言（如XML模式定义）进行描述。只要所有系统都遵守其发布的合约，它们就可以相互操作，对系统内部的更改永远不会影响任何其他系统。每个系统都负责将自己的内部实现与其合约进行翻译

REST-再现状态传输。物理 协议是HTTP。基本上，REST是网络上所有可由URL唯一标识的不同资源。可以对这些资源执行的所有操作都可以由一组有限的动词（“CRUD”动词）描述，这些动词反过来映射到HTTP动词。

REST的“重量级”远不如SOAP。

Web服务的工作

小开

SOAP-简单对象访问协议是一个协议！

REST-再现状态转移是一个建筑风格！

SOAP是一个用于传输消息的XML协议，通常通过HTTP

REST和SOAP是可以说<强>不互斥的。RESTful架构可能使用HTTP或SOAP或其他一些通信协议。REST针对Web进行了优化，因此HTTP是一个完美的选择。HTTP也是Roy Fielding论文中讨论的只有协议。

尽管REST和SOAP显然非常不同，但这个问题确实说明了REST和HTTP经常同时使用的事实。这主要是由于HTTP的简单性及其对RESTful原则的非常自然的映射。

REST基本原则

客户端-服务器通信

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

无国籍

每个客户端对服务器的请求都要求完全表示其状态。服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态。因此，所有状态都必须保存在客户端上。我们将在后面更详细地讨论无状态表示。

可缓存

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

统一接口

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

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

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

小开

SOAP Web服务和REST Web服务都可以使用HTTP协议和其他协议（仅提及SOAP可以是REST的底层协议）。我将只谈论与SOAP和REST相关的HTTP协议，因为这是它们最常见的用法。

SOAP

SOAP（“简单”对象访问协议）是一个协议（和w3c标准）。它定义了如何创建、发送和处理SOAP消息。

  • SOAP消息是具有特定结构的XML文档：它们包含一个包含标头和主体部分的信封。主体包含我们想要发送的XML格式的实际数据。有两种编码风格，但是我们通常选择文字，这意味着我们的应用程序或其SOAP驱动程序对数据进行XML序列化和非序列化。

  • SOAP消息作为带有SOAP+XML MIME子类型的HTTP消息传输。这些HTTP消息可以是多部分的，因此我们可以选择将文件附加到SOAP消息。

  • 显然，我们使用客户端-服务器架构，所以SOAP客户端向SOAP网络服务器发送请求，服务向客户端发送响应。大多数网络服务使用WSDL文件来描述服务。WSDL文件包含我们要发送的数据的XML模式（以下简称XSD）和定义网络服务如何绑定到HTTP协议的WSDL绑定。有两种绑定样式： RPC和文档。通过RPC样式绑定，SOAP主体包含带有参数（HTTP请求）或返回值（HTTP响应）的操作调用的表示。参数和返回值根据XSD进行验证。通过文档样式绑定，SOAP正文包含一个针对XSD进行验证的XML文档。我认为文档绑定样式更适合基于事件的系统，但我从未使用过那种绑定样式。RPC绑定样式更普遍，所以大多数人通过分布式应用程序将SOAP用于XML/RPC目的。网络服务通常通过询问UDDI服务器来找到对方。UDDI服务器是存储网络服务位置的注册表。

SOAPRPC

因此，在我看来，最流行的SOAP Web服务使用RPC绑定样式和文字编码样式，它具有以下属性：

  • 它将URL映射到操作。
  • 它发送带有SOAP+XML MIME子类型的消息。
  • 它可以有一个服务器端会话存储，对此没有任何限制。
  • SOAP客户端驱动程序使用服务的WSDL文件将RPC操作转换为方法。客户端应用程序通过调用这些方法与SOAP Web服务通信。因此，大多数SOAP客户端通过接口更改（结果方法名称和/或参数更改）中断。
  • 使用RDF编写不会因接口更改而中断的SOAP客户端并通过语义学查找操作是可能的，但是语义网络服务非常罕见，它们不一定有非中断客户端（我猜）。

REST

REST（表示状态传输）是一种架构风格，在Roy Fielding的论文中描述。它不像SOAP那样关心协议。它从没有约束的空架构风格开始，并逐一定义REST架构的约束。人们使用术语RESTful来描述满足所有REST约束的Web服务，但根据Roy Fielding的说法，没有REST级别这样的东西。当一个Web服务不满足每个REST约束时，它就不是一个REST Web服务。

REST约束

  • 客户端-服务器架构-我想这部分大家都很熟悉。REST客户端与REST Web服务通信，Web服务维护公共数据-资源状态-并将其提供给客户端。
  • 无状态-缩写：REST的“状态传输”部分。客户端维护客户端状态（会话/应用程序状态），因此服务不能有会话存储。客户端通过每个请求将客户端状态的相关部分传输到服务，服务以资源状态的相关部分响应（由它们维护）。因此请求没有上下文，它们总是包含处理它们所需的信息。例如通过HTTP基本身份验证，用户名和密码由客户端存储，它在每个请求时发送它们，因此每个请求都进行身份验证。这与仅通过登录进行身份验证的常规Web应用程序非常不同。如果需要，我们可以使用任何客户端数据存储机制，如内存（javascript）、cookie、localStorage等…来持久化客户端状态的某些部分。无状态约束的原因是，当服务器不必维护每个客户端的会话时，它可以很好地扩展-即使负载非常高（数百万用户）。
  • 缓存-响应必须包含有关它的信息，客户端是否可以缓存。这进一步提高了可扩展性。
  • 统一接口

    • 资源标识-REST资源与RDF资源相同。根据Fielding的说法，如果你可以命名一些东西，那么它可以是一个资源，例如：“当前本地天气”可以是一个资源，或者“您的手机”可以是一个资源，或者“特定的Web文档”可以是一个资源。要识别资源，您可以使用资源标识符：URL和URN（例如书号ISBN）。单个标识符应该只属于特定资源，但是单个资源可以有多个标识符，我们经常利用这些标识符，例如通过使用https://example.com/api/v1/users?offset=50&count=25等URL进行分页。URL有一些规格，例如具有相同路径但不同查询不相同的URL，或者路径部分应该包含URL的分层数据，查询部分应该包含非分层数据。这些是如何通过REST创建URL的基础知识。URL结构只对服务开发人员重要，真正的REST客户端不关心它。另一个经常被问到的问题是API版本控制，这是一个简单的问题，因为根据Fielding的说法，资源唯一不变的是语义学。如果语义学改变，那么你可以添加一个新的版本号。您可以使用经典的3号版本控制并仅向URL添加主要数字（https://example.com/api/v1/）。因此，通过向下兼容的更改，什么也不会发生，通过非向下兼容的更改，您将拥有具有新API根https://example.com/api/v2/的非向下兼容语义学。所以旧客户端不会中断，因为他们可以将https://example.com/api/v1/与旧语义学一起使用。

    • 通过表示操纵资源-您可以通过将资源的预期表示——以及HTTP方法和资源标识符——发送到REST服务来操纵与资源（资源状态）相关的数据。例如，如果您想在结婚后重命名用户，您可以发送一个PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}请求，其中{name: "Mrs Smith"}是预期资源状态的JSON表示，换句话说：新名称。反之亦然，服务会向客户端发送资源表示，以更改它们的状态。例如，如果我们想读取新名称，我们可以发送一个GET https://example.com/api/v1/users/1?fields="name"检索请求，这会导致一个200 ok, {name: "Mrs Smith"}响应。因此，我们可以使用此表示来更改客户端状态，例如我们可以显示“欢迎来到我们的页面，史密斯夫人！”消息。资源可以有许多表示，具体取决于资源标识符（URL）或我们随请求发送的accept标头。例如，如果请求image/jpeg，我们可以发送史密斯夫人的图像（可能不是裸体）。

    • 自描述消息-消息必须包含有关如何处理它们的信息。例如URI和HTTP方法、内容类型标头、缓存标头、描述数据含义的RDF等…使用标准方法很重要。了解HTTP方法的产品规格很重要。例如GET意味着检索请求URL标识的信息，DELETE意味着要求服务器删除给定URL标识的资源，等等… HTTP状态码也有产品规格，例如200意味着成功，201意味着创建了新资源，404意味着在服务器上找不到请求的资源，等等…使用现有标准是REST的重要组成部分。

    • 超媒体作为应用程序状态的引擎（以下简称HATEOAS）-超媒体是一种可以包含超链接的媒体类型。通过网络，我们遵循链接——由超媒体格式（通常是超文本标记语言）描述——来实现目标，而不是将URL输入地址栏。REST遵循相同的概念，服务发送的表示可以包含超链接。我们使用这些超链接向服务发送请求。通过响应，我们获得数据（可能还有更多链接），我们可以使用这些数据来构建新的客户端状态，依此类推……这就是为什么超媒体是应用程序状态（客户端状态）的引擎。你可能想知道客户端如何识别和关注超链接？对于人类来说，这非常简单，我们阅读链接的标题，也许填写输入字段，然后只需单击一下。对于机器，我们必须为RDF链接（通过JSON-LD和九头蛇）或超媒体特定解决方案（例如IANA链接关系和供应商特定的MIME类型和HAL+JSON）添加语义学。有许多机器可读的xml和JSON超媒体格式，只是其中的一个简短列表：

      有时候很难选择…

  • 分层系统-我们可以在客户端和服务之间使用多层。他们中的任何一个都不应该知道所有这些附加层，只是紧挨着它的层。这些层可以通过应用缓存和负载平衡来提高可扩展性，或者它们可以强制执行安全策略。
  • 按需代码-我们可以发回扩展客户端功能的代码，例如将javascript代码发送到浏览器。这是REST的唯一可选约束。

REST webservice-SOAP RPC webservice差异

因此，REST Web服务与SOAP Web服务（具有RPC绑定样式和文字编码样式）非常不同

  • 它定义了一个统一接口（协议的集成）。
  • 它将URL映射到资源（而不是操作）。
  • 它使用任何MIME类型（而不仅仅是SOAP+XML）发送消息。
  • 它具有无状态通信，因此它不能具有服务器端会话存储。（SOAP对此没有限制）
  • 它为超媒体提供服务，客户端使用该超媒体包含的链接来请求服务。（SOAP RPC使用WSDL文件中描述的操作绑定）
  • 它不会因URL更改而中断，只会因语义学更改而中断。（SOAP RPC客户端不使用RDF语义学而因WSDL文件更改而中断。）
  • 由于其无状态行为，它比SOAP Web服务更好地扩展。

等等…

SOAP RPC Web服务不满足所有REST约束：

  • 客户端-服务器架构-始终
  • 无状态-可能
  • 缓存-可能
  • 统一接口-永不
  • 分层系统-从未
  • 按需代码（可选）-可能
小开

SOAP-简单对象访问协议

SOAP是通过Internet传输消息或少量信息的轻微方式。SOAP消息以xml格式格式化，通常以控制超文本传输协议的方式发送。

REST-"再现状态转移"

REST是粉丝和服务器之间可能发生和接收信息的基本过程，它没有明确定义的标准。您可以以JSON、xml甚至纯文本的形式发送和接受信息。与SOAP相比，它的权重较轻。


提交答案