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

时间：2008-10-16 19:24:15

标签： rest soap

有人可以用简单的英语解释什么是REST和什么是SOAP？ Web Services如何工作？

13 个答案:

答案 0 :(得分：1585)

关于SOAP和REST的简单说明

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

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

休息 - 具有代表性的州转移

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

enter image description here

答案 1 :(得分：320)

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

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

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

具象状态转移（REST）：

  • REST无需通过HTTP，但我的大多数要点都会产生HTTP偏见。
  • REST非常轻量级，它说等一下，我们不需要SOAP创建的所有这些复杂性。
  • 通常使用普通的HTTP方法，而不是描述所有内容的大型XML格式。例如，要获取资源，请使用HTTP GET，将资源放在使用HTTP PUT的服务器上。要删除服务器上的资源，请使用HTTP DELETE。
  • REST非常简单，因为它使用HTTP GET，POST和PUT方法来更新服务器上的资源。
  • REST通常最适用于Resource Oriented Architecture（ROA）。在这种思维模式中，一切都是资源，你可以在这些资源上运作。
  • 只要您的编程语言具有HTTP库，并且大部分都是如此，您就可以非常轻松地使用REST HTTP协议。
  • 可以根据请求简单地提供二进制数据或二进制资源。

有endless debates on REST vs SOAP on google。

My favorite is this one。 2013年11月27日更新：保罗·普雷斯科德的网站似乎已脱机，本文不再可用，副本虽然可以在Wayback Machine上找到，也可以在CiteSeerX上找到。

答案 2 :(得分：39)

这是您将找到的最简单的解释。

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

how-i-explained-rest-to-my-wife（原始链接）
how-i-explained-rest-to-my-wife（2013-07-19工作链接）

答案 3 :(得分：37)

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

REST - 代表性状态转移是架构风格！

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

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

虽然REST和SOAP显然非常不同，但问题确实说明了REST和HTTP经常串联使用的事实。这主要是由于HTTP的简单性以及它与RESTful原则的非常自然的映射。

基本REST原则

客户端 - 服务器通信

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

<强>无国籍

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

<强>可缓存

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

统一界面

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

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

有关 REST 以及上述项目符号的更多详细信息，请参阅 REST设计主体上的此博客post。

答案 4 :(得分：12)

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

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

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

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

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

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

答案 5 :(得分：7)

SOAP webservices和REST webservices都可以使用HTTP协议和其他协议（只是提到SOAP可以是REST的底层协议）。我将仅讨论与HTTP协议相关的SOAP和REST，因为这是最常用的。

SOAP

SOAP（＆＃34;简单＆＃34;对象访问协议）是一种协议（和W3C standard）。它定义了如何创建，发送和处理SOAP消息。

  • SOAP消息是具有特定结构的XML文档：它们包含一个包含标题和正文部分的信封。正文包含XML格式的实际数据 - 我们要发送。有two encoding styles，但we usually choose literal，这意味着我们的应用程序或其SOAP驱动程序执行XML序列化和数据的反序列化。

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

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

SOAP RPC

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

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

REST

REST（代表性状态转移）是一种架构风格，在Roy Fielding的dissertation中有所描述。它不像SOAP那样关注协议。它以没有约束的null体系结构样式开始，并逐个定义REST体系结构的约束。人们使用术语RESTful来实现所有REST约束的web服务，但根据Roy Fielding的说法，没有REST levels这样的东西。 When a webservice does not meet with every single REST constraint, then it is not a REST webservice.

REST约束

  • 客户端 - 服务器架构 - 我认为这部分对每个人都很熟悉。 REST客户端与REST Web服务进行通信，Web服务在此后维护公共数据 - 资源状态 - 并将其提供给客户端。
  • 无国籍 - ＆＃34;州转移＆＃34;部分缩写：REST。客户端维护客户端状态（会话/应用程序状态），因此服务不能具有会话存储。客户端通过对服务的每个请求传输客户端状态的相关部分，这些服务响应资源状态的相关部分（由它们维护）。因此请求没有上下文，它们总是包含处理它们的必要信息。例如，通过HTTP basic auth，客户端存储用户名和密码，并且每次请求都会发送它们，因此每次请求都会进行身份验证。这与仅通过登录进行身份验证的常规Web应用程序非常不同。我们可以使用任何客户端数据存储机制，如内存（javascript），cookie，localStorage等......如果需要，可以保留客户端状态的某些部分。无状态约束的原因是服务器可以很好地扩展 - 即使是非常高的负载（数百万用户） - 当它不必维护每个客户端的会话时。
  • 缓存 - 响应必须包含有关它的信息，客户端是否可以缓存。这进一步提高了可扩展性。

  • 统一界面

    • 资源标识 - REST资源与RDF资源相同。根据菲尔丁的说法，如果你可以命名，那么它可以是一种资源，例如：＆＃34;当前的当地天气＆＃34;可以是资源，也可以是＆＃34;您的手机＆＃34;可以是资源，也可以是＆＃34;特定的网络文档＆＃34;可以是一种资源。要标识资源，您可以使用资源标识符：URL和URN（例如ISBN number by books）。单个标识符应仅属于特定资源，但单个资源可以包含许多标识符，我们经常利用这些标识符，例如通过对https://example.com/api/v1/users?offset=50&count=25等URL进行分页。 URL有一些specifications，例如具有相同路径但不同查询的URL不相同，或者路径部分应包含URL的层次数据，而查询部分应包含非分层数据。这些是如何通过REST创建URL的基础知识。顺便说一句。 URL结构仅对服务开发人员有用，真正的REST客户端不关心它。另一个经常被问到的问题是API版本控制，这很简单，因为根据Fielding的说法，资源唯一不变的是语义。如果语义更改，则可以添加新版本号。您可以使用经典3 number versioning并仅将主要数字添加到网址（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"}响应。所以我们可以使用这种表示来改变客户端状态，例如我们可以显示一个＆＃34;欢迎来到我们的页面史密斯夫人！＆＃34;信息。资源可以有多种表示形式，具体取决于我们随请求发送的资源标识符（URL）或accept标头。例如，如果请求image/jpeg，我们可以发送史密斯夫人的图像（可能不是裸体）。
    • 自描述消息 - 消息必须包含有关如何处理它们的信息。例如URI和HTTP方法，内容类型标头，缓存标头，描述数据含义的RDF等......使用标准方法很重要。了解HTTP方法的specification非常重要。例如，GET表示检索由请求URL标识的信息，DELETE表示要求服务器删除由给定URL标识的资源，依此类推...... HTTP状态代码也有specification，例如200表示success，201表示已创建新资源，404表示在服务器上找不到所请求的资源等...使用现有标准是REST的重要组成部分。

    • 超媒体作为应用程序状态的引擎（以下称为HATEOAS） - 超媒体是一种可以包含超链接的媒体类型。通过网络，我们遵循链接 - 通过超媒体格式（通常是HTML）描述 - 来实现目标，而不是在URL中键入URL。 REST遵循相同的概念，服务发送的表示可以包含超链接。我们使用这些超链接向服务发送请求。通过响应，我们可以获得可用于构建新客户端状态的数据（可能还有更多链接）等等......这就是超媒体是应用程序状态（客户端状态）的引擎的原因。您可能想知道客户如何识别并遵循超链接？通过人类它非常简单，我们读取链接的标题，可能填充输入字段，然后只需单击一下。通过机器，我们必须将语义添加到RDF的链接（JSON-LD与Hydra）或特定于超媒体的解决方案（例如IANA link relations和vendor specific MIME types {{3} }）。有许多机器可读的HAL+JSON和XML，只是一个简短的列表：

      有时很难选择......

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

REST webservice - SOAP RPC Web服务差异

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

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

依旧......

SOAP RPC Web服务不符合所有REST约束：

  • 客户端 - 服务器架构 - 始终
  • 无国籍 - Collection+JSON
  • 缓存 - possible
  • 统一界面 - 从不
  • 分层系统 - possible
  • 按需代码（可选） - 可能

答案 6 :(得分：6)

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

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

以下链接表示 REST ＆amp; SOAP 以极其清晰的方式。

REST vs SOAP

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

答案 7 :(得分：5)

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

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

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

答案 8 :(得分：2)

我认为这很容易解释。请，欢迎任何人纠正我或添加到此。

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

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

答案 9 :(得分：2)

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

答案 10 :(得分：2)

REST是一种用于设计网络应用程序的架构风格。我们的想法是，不是使用CORBA，RPC或SOAP等复杂机制来连接机器，而是使用简单的HTTP在机器之间进行调用。

答案 11 :(得分：1)

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

SOAP 是通过Internet传输消息或少量信息的一种方式。 SOAP 消息采用 XML 格式化，通常通过控制 HTTP 发送。

REST - “代表国家转移”

REST 是一种基本的可能性，可以在风扇和服务器之间接收信息，并且没有明确定义许多标准。您可以 JSON ， XML 甚至纯文本发送和接受信息。与 SOAP 相比，它的重量轻。

答案 12 :(得分：-4)

基于SOAP的Web服务 简而言之，基于SOAP的服务模型将世界视为同等对等体的生态系统，这些生态体无法相互控制，但必须通过尊重已发布的合同来协同工作。这是有效的 凌乱的现实世界的模型，基于元数据的合同构成了SOAP服务接口。

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

SOAP假设所有系统都是独立的，并且没有系统知道另一个和内部功能的内部。 大多数此类系统可以做的是向彼此发送消息，并希望他们将被采取行动。系统发布他们承诺的合同，其他系统依靠这些合同与他们交换信息。

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

REST - 代表性国家转移。身体上的 协议是HTTP。基本上，REST是Web上可由URL唯一标识的所有不同资源。可以在这些资源上执行的所有操作都可以通过一组有限的动词（“CRUD”动词）来描述，这些动词又映射到HTTP动词。

REST比SOAP更“重量级”。

Working of web service

相关问题
最新问题