有人可以用简单的英语解释REST和SOAP吗？Web服务如何工作？

关于SOAP和REST的简单说明

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

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

休息-代表性状态转移

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

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

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

• SOAP在HTTP或有时在TCP / IP的基础上构建XML协议。
• SOAP描述了功能和数据类型。
• SOAP是XML-RPC的后继产品，并且非常相似，但是描述了一种标准的通信方式。
• 几种编程语言都对SOAP提供了本机支持，通常可以向其提供Web服务URL，并且可以在不需要特定代码的情况下调用其Web服务功能。
• 必须首先将发送的二进制数据编码为诸如base64编码的格式。
• 有几种与之相关的协议和技术：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通常最好与面向资源的体系结构（ROA）一起使用。在这种思维方式下，一切都是资源，您将在这些资源上进行操作。
• 只要您的编程语言具有HTTP库（并且大多数语言都具有），您就可以非常轻松地使用REST HTTP协议。
• 二进制数据或二进制资源可以简单地根据其请求进行传递。

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

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

休息

我知道REST的主要思想非常简单。我们使用网络浏览器已有多年，我们已经看到了网站的简易性，灵活性，性能等。HTML网站使用超链接和表单作为用户交互的主要方式。他们的主要目标是让我们（客户）仅知道我们可以在当前状态下使用的那些链接。REST只是简单地说：“为什么不使用相同的原理通过我们的应用程序来驱动计算机，而不是人类客户？” 结合使用WWW基础架构的功能，您将获得构建强大的分布式应用程序的杀手级工具。

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

令人惊讶的是，所有答案似乎都集中在消息格式或HTTP动词用法上。实际上，消息格式根本没有关系，只要服务开发人员对其进行了记录，REST就可以使用任何一种消息格式。HTTP动词仅使服务成为CRUD服务，但尚未实现RESTful。真正将服务转变为REST服务的是将超链接（也称为超媒体控件）与数据一起嵌入服务器响应中，并且超链接的数量必须足以使任何客户端从这些链接中选择下一步操作。

不幸的是，除了Roy Fielding的论文之外，很难在Web上的REST上找到正确的信息。（他是派生REST的人）。我会推荐“ REST in Practice”这本书，因为它提供了有关如何从SOAP演变为REST的全面分步教程。

肥皂

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

比较一下

比较任何形式的RPC与REST时，传输协议，消息格式，xsd，wsdl等详细信息都无关紧要。主要区别在于，RPC服务通过在RPC API中设计自己的应用程序协议来重新设计自行车，而该协议只有它知道的语义。因此，所有客户端都必须在使用服务之前了解此协议，并且由于所有请求的专有语义，因此无法构建通用结构（如缓存）。此外，RPC API并不建议在当前状态下允许执行哪些操作，这必须从其他文档中得出。另一方面，REST意味着使用统一的接口来允许各种客户端对API语义有所了解，并使用超媒体控件（链接）突出显示每种状态下的可用选项。从而，

从某种意义上说，SOAP（与其他任何RPC一样）都是试图通过服务边界进行隧道传输，将连接媒体视为仅能够传输消息的黑匣子。REST是一个决定，要承认Web是一个巨大的分布式信息系统，可以按原样接受世界并学习掌握它而不是与之抗争。

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

更新资料

我的经验出乎意料地表明，REST开发比SOAP更困难。至少对于.NET。尽管有像ASP.NET Web API这样的出色框架，但是没有能够自动生成客户端代理的工具。就像“添加Web服务参考”或“添加WCF服务参考”一样。必须手动编写所有序列化和服务查询代码。而且，那是很多样板代码。我认为REST开发需要与每个开发平台的WSDL和工具实现类似的东西。实际上，似乎有一个很好的基础：WADL或WSDL 2.0，但是似乎没有一个标准得到很好的支持。

更新（2016年1月）

事实证明，现在有各种各样的 REST API定义工具。我个人的喜好目前是RAML。

Web服务如何工作

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

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

本文将丈夫带到妻子的叙述中，在此，丈夫以纯俗的方式向妻子解释了REST。必读！

我如何向我妻子解释休息（原文链接）
我如何向我妻子解释休息（2013-07-19工作链接）

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是针对Web优化的，因此REST在HTTP上的普及程度令人难以置信！

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

有关REST和上述项目符号的更多详细信息，请参见有关REST设计原理的博客文章。

我喜欢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- *

SOAP Web服务和REST Web服务都可以使用HTTP协议和其他协议（只是说SOAP可以是REST的基础协议）。我将仅讨论与HTTP协议相关的SOAP和REST，因为这是它们中最常见的用法。

肥皂

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

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

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

• 显然，我们使用的是客户端-服务器体系结构，因此SOAP客户端将请求发送到SOAP Web服务，而服务将响应发送回客户端。大多数Web服务都使用WSDL文件来描述服务。WSDL文件包含我们要发送的数据的XML模式（以下简称XSD）和WSDL绑定，该绑定定义了如何将Web服务绑定到HTTP协议。有两种装订样式：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客户端，但是语义Web服务非常罕见，并且它们不一定具有不中断的客户端（我想）。

休息

REST（表示状态转移）是一种架构样式，在Roy Fielding 的论文中进行了描述。它不像SOAP那样关注协议。它以没有约束的空体系结构样式开始，并一一定义了REST体系结构的约束。人们对满足所有REST约束的Web服务使用术语RESTful，但是根据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号）。单个标识符应该仅属于特定资源，但是单个资源可以具有许多标识符，例如，我们经常通过分页使用诸如URL的方式来利用这些标识符https://example.com/api/v1/users?offset=50&count=25。网址有一些规范，例如，具有相同路径但不同查询的URL不相同，或者路径部分应包含URL的层次数据，而查询部分应包含非层次数据。这些是如何通过REST创建URL的基础。顺便说一句。URL结构仅对服务开发人员重要，真正的REST客户端与此无关。另一个经常被问到的问题是API版本控制，这是一个简单的问题，因为根据Fielding的观点，唯一不变的资源就是语义。如果语义发生变化，则可以添加新的版本号。您可以使用经典的3位数版本控制，并且仅将主要数字添加到网址中（https://example.com/api/v1/）。因此，通过向后兼容更改不会发生任何事情，通过非向后兼容更改，您将具有带有新API root的向后兼容语义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）-超媒体是一种可以包含超链接的媒体类型。在网络上，我们遵循以超媒体格式（通常为HTML）描述的链接来实现目标，而不是在addres栏中键入URL。REST遵循相同的概念，服务发送的表示形式可以包含超链接。我们使用这些超链接将请求发送到服务。通过响应，我们获得了可用于构建新客户端状态的数据（可能还有更多链接），依此类推……这就是为什么超媒体是应用程序状态（客户端状态）的引擎。您可能想知道客户如何识别和跟踪超链接？对人类来说，这很简单，我们阅读链接的标题，也许填写输入字段，然后单击一下即可。带有Hydra的JSON-LD）或超媒体特定的解决方案（例如IAL链接关系和HAL + JSON提供的特定于供应商的MIME类型）。有许多机器可读的XML和JSON超媒体格式，只是其中的一小部分：

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • 警笛
    • 集合+ JSON

    有时候很难选择...

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

REST Web服务-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约束：

• 客户端-服务器体系结构-始终
• 无状态- 可能
• 缓存- 可能
• 统一界面-从不
• 分层系统- 从不
• 按需代码（可选）-可能

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

WebService本质上是公开某些功能或数据的逻辑部分（您可能会模糊地将其称为方法）。实现的客户端（从技术上来说，就是“ 消耗”这个词）只需要知道该方法将接受的参数是什么，以及它将返回的数据类型（如果有的话）。

以下链接以一种非常清晰的方式说明了有关REST和SOAP的全部内容。

REST与SOAP

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

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

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

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

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

SOAP是一种消息格式，供断开连接的系统（例如，跨Internet）用于交换信息/数据。它处理来回的XML消息。

Web服务发送或接收SOAP消息。它们的工作方式取决于所使用的语言。

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

REST是用于设计网络应用程序的体系结构样式。这个想法是，与其使用诸如CORBA，RPC或SOAP之类的复杂机制在计算机之间进行连接，不如使用简单的HTTP在计算机之间进行调用。

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

SOAP只不过是在Internet上传输消息或少量信息而已。SOAP消息采用XML格式，通常通过HTTP进行发送。

REST –“代表状态转移”

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

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

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

SOAP假定所有系统都是独立的，并且没有系统对另一个内部功能和内部功能有任何了解。这样的系统最能做的就是互相发送消息，并希望它们能被执行。系统发布它们承诺履行的合同，而其他系统则依靠这些合同与它们交换消息。

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

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

REST比SOAP的“重量级”要少得多。

网络服务的工作