14 回答
关于 SOAP 和 REST 的简单解释
SOAP - “简单对象访问协议”
SOAP 是一种通过 Internet 传输消息或少量信息的方法。SOAP 消息采用 XML 格式，通常使用 HTTP（超文本传输协议）发送。
休息 - 代表性状态转移
Rest 是一种在客户端和服务器之间发送和接收数据的简单方法，它没有定义很多标准。您可以以 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 协议。
- 二进制数据或二进制资源可以根据他们的请求简单地交付。
在 google 上有无休止的关于 REST 与 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”一书，因为它提供了关于如何从 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 全天候可用，这就是它是一个服务的原因。当然，它为它的客户解决了一些问题（否则为什么有人会使用 Web 服务）。
这是你能找到的最简单的解释。
这篇文章讲述了一对夫妻的故事，丈夫用纯粹的外行术语向他的妻子解释了 REST。必读！
how-i-explained-rest-to-my-wife（原始链接）
how-i-explained-rest-to-my-wife（2013-07-19 工作链接）
SOAP——简单对象访问协议是一种协议！
REST-REpresentational State Transfer是一种架构风格！
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 over HTTP 非常受欢迎！
上述概念代表了 REST 的定义特征，并将 REST 架构与其他架构（如 Web 服务）区分开来。请注意，REST 服务是一种 Web 服务，但 Web 服务不一定是 REST 服务。
有关REST和上述项目符号的更多详细信息，请参阅这篇关于REST 设计原则的博客文章。
我喜欢 Brian R. Bondy 的回答。我只是想补充一点，Wikipedia 提供了对REST的清晰描述。这篇文章将它与 SOAP 区分开来。
REST 是状态信息的交换，尽可能简单地完成。
SOAP 是一种使用 XML 的消息协议。
许多人从 SOAP 迁移到 REST 的主要原因之一是与基于 SOAP 的 Web 服务相关的 WS-*（称为 WS splat）标准非常复杂。有关规格列表，请参阅wikipedia。这些规范中的每一个都非常复杂。
编辑：由于某种原因，链接显示不正确。REST = http://en.wikipedia.org/wiki/REST
SOAP webservices 和 REST webservices 都可以使用 HTTP 协议和其他协议（只是提到 SOAP 可以是 REST 的底层协议）。我将只讨论与 HTTP 协议相关的 SOAP 和 REST，因为这是它们最常用的用法。
肥皂
SOAP（“简单”对象访问协议）是一种协议（也是W3C 标准）。它定义了如何创建、发送和处理 SOAP 消息。
SOAP 消息是具有特定结构的 XML 文档：它们包含一个包含标头和正文部分的信封。正文包含 XML 格式的实际数据——我们要发送。有两种编码风格，但我们通常选择文字，这意味着我们的应用程序或其 SOAP 驱动程序对数据进行 XML 序列化和反序列化。
SOAP 消息作为带有 SOAP+XML MIME 子类型的 HTTP 消息传播。这些 HTTP 消息可以是多部分的，因此我们可以选择将文件附加到 SOAP 消息。
显然，我们使用客户端-服务器架构，因此 SOAP 客户端向 SOAP 网络服务发送请求，而服务将响应发送回客户端。大多数 Web 服务使用 WSDL 文件来描述服务。WSDL 文件包含我们要发送的数据的 XML Schema（以下称为 XSD）和 WSDL 绑定，它定义了 Web 服务如何绑定到 HTTP 协议。有两种装订方式: RPC 和文件。通过 RPC 样式绑定，SOAP 主体包含带有参数（HTTP 请求）或返回值（HTTP 响应）的操作调用的表示。参数和返回值根据 XSD 进行验证。通过文档样式绑定，SOAP 主体包含一个针对 XSD 进行验证的 XML 文档。我认为文档绑定风格更适合基于事件的系统，但我从未使用过这种绑定风格。RPC 绑定样式更为流行，因此大多数人通过分布式应用程序将 SOAP 用于 XML/RPC 目的。Web 服务通常通过询问UDDI服务器来找到彼此。UDDI 服务器是存储 Web 服务位置的注册表。
SOAP RPC
所以 - 在我看来 - 最流行的 SOAP webservice 使用 RPC 绑定样式和文字编码样式，它具有以下属性：
- 它将 URL 映射到操作。
- 它发送带有 SOAP+XML MIME 子类型的消息。
- 它可以有一个服务器端会话存储，对此没有任何限制。
- SOAP 客户端驱动程序使用服务的 WSDL 文件将 RPC 操作转换为方法。客户端应用程序通过调用这些方法与 SOAP Web 服务进行通信。因此，大多数 SOAP 客户端会因接口更改（导致方法名称和/或参数更改）而中断。
- 可以使用 RDF 编写不会因接口更改而中断的 SOAP 客户端，并通过语义查找操作，但语义 Web服务非常罕见，它们不一定有非中断客户端（我猜）。
休息
REST（representational state transfer）是一种架构风格，在Roy Fielding的论文中有所描述。它不像 SOAP 那样关心协议。它从没有约束的空架构样式开始，并一一定义了 REST 架构的约束。人们使用术语 RESTful 来表示满足所有 REST 约束的 Web 服务，但根据 Roy Fielding 的说法，没有诸如REST 级别之类的东西。当一个 Web 服务不满足每一个 REST 约束时，它就不是一个 REST Web 服务。
REST 约束
- 客户端——服务器架构——我想这部分大家都很熟悉了。REST 客户端与 REST Web 服务通信，Web 服务维护公共数据 - 此后的资源状态 - 并将其提供给客户端。
- 无状态 - 缩写的“状态转移”部分：REST。客户端维护客户端状态（会话/应用程序状态），因此服务不能有会话存储。客户端通过每个请求将客户端状态的相关部分传输到服务，这些服务以资源状态的相关部分（由它们维护）进行响应。所以请求没有上下文，它们总是包含处理它们的必要信息。例如，通过 HTTP 基本身份验证，用户名和密码由客户端存储，并随每个请求一起发送，因此每个请求都会进行身份验证。这与仅通过登录进行身份验证的常规 Web 应用程序非常不同。我们可以使用任何客户端数据存储机制，如内存中（javascript）、cookies、localStorage 等...... 如果我们愿意，可以保留客户端状态的某些部分。无状态约束的原因是服务器可以很好地扩展 - 即使负载非常高（数百万用户） - 当它不必维护每个客户端的会话时。
- 缓存 - 响应必须包含有关它是否可以被客户端缓存的信息。这进一步提高了可扩展性。
- 统一的界面
资源标识——REST 资源与RDF资源相同。根据菲尔丁的说法，如果可以命名，那么它可以是资源，例如：“当前当地天气”可以是资源，或者“您的手机”可以是资源，或者“特定的网络文档”可以是资源。一种资源。要识别资源，您可以使用资源标识符：URL 和 URN（例如ISBN number by books）。一个标识符应该只属于一个特定的资源，但一个资源可以有很多标识符，我们经常利用这些标识符，例如使用
https://example.com/api/v1/users?offset=50&count=25. 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"}回复。所以我们可以使用这个表示来改变客户端状态，例如我们可以显示“欢迎来到我们的页面 Mrs Smith！” 信息。一个资源可以有多种表示形式，具体取决于资源标识符 (URL) 或accept我们随请求发送的标头。例如，如果需要，我们可以发送史密斯夫人的图像（可能不是裸体）image/jpeg。自描述消息 - 消息必须包含有关如何处理它们的信息。例如 URI 和 HTTP 方法、内容类型标头、缓存标头、描述数据含义的 RDF 等……使用标准方法很重要。了解HTTP 方法的规范很重要。例如 GET 表示检索由请求 URL 标识的信息，DELETE 表示要求服务器删除由给定 URL 标识的资源，等等...... HTTP 状态代码也有一个规范，例如 200 表示成功，201 表示新资源已创建，404 表示在服务器上未找到请求的资源等...使用现有标准是 REST 的重要组成部分。
超媒体作为应用程序状态的引擎（以下称为 HATEOAS）——超媒体是一种可以包含超链接的媒体类型。通过网络，我们跟随链接 - 由超媒体格式（通常是 HTML）描述 - 来实现目标，而不是在地址栏中输入 URL。REST 遵循相同的概念，服务发送的表示可以包含超链接。我们使用这些超链接向服务发送请求。通过响应，我们得到数据（可能还有更多链接），我们可以使用这些数据来构建新的客户端状态，等等……这就是为什么超媒体是应用程序状态（客户端状态）的引擎。您可能想知道客户如何识别和跟踪超链接？对人类来说，这很简单，我们阅读链接的标题，也许填写输入字段，然后单击一下。JSON-LD with Hydra）或超媒体特定解决方案（例如IANA 链接关系和HAL+JSON的供应商特定 MIME 类型）。有许多机器可读的XML和JSON 超媒体格式，只是其中的一小部分：
有时很难选择...
- 分层系统——我们可以在客户端和服务之间使用多层。他们都不应该知道所有这些附加层，只是它旁边的层。这些层可以通过应用缓存和负载平衡来提高可伸缩性，或者它们可以强制执行安全策略。
- 按需代码 - 我们可以将扩展客户端功能的代码（例如 javascript 代码）发送回浏览器。这是 REST 的唯一可选约束。
REST webservice - SOAP RPC webservice 区别
所以 REST webservice 与 SOAP webservice 非常不同（具有 RPC 绑定样式和文字编码样式）
- 它定义了一个统一的接口（而不是协议）。
- 它将 URL 映射到资源（而不是操作）。
- 它发送具有任何 MIME 类型的消息（而不仅仅是 SOAP+XML）。
- 它具有无状态通信，因此不能具有服务器端会话存储。（SOAP 对此没有限制）
- 它为超媒体提供服务，客户端使用该超媒体包含的链接来请求服务。（SOAP RPC 使用 WSDL 文件中描述的操作绑定）
- 它不会因 URL 更改而仅因语义更改而中断。（不使用 RDF 语义的 SOAP RPC 客户端会因 WSDL 文件更改而中断。）
- 由于其无状态行为，它比 SOAP Web 服务更易于扩展。
等等...
SOAP RPC 网络服务不满足所有 REST 约束：
好吧，我将从第二个问题开始：什么是 Web 服务？，原因很明显。
WebServices 本质上是公开某些功能或数据的逻辑片段（您可能模糊地称为方法）。客户端实现（从技术上讲，消费就是这个词）只需要知道该方法将接受的参数是什么以及它将返回的数据类型（如果有的话）。
以下链接以极其清晰的方式说明了有关REST和SOAP的全部内容。
如果您还想知道何时选择什么（REST 或 SOAP），那就更有理由去经历它！
SOAP 和 REST 都指不同系统相互通信的方式。
REST 使用类似于您的浏览器与 Web 服务器的通信的技术来执行此操作：使用 GET 请求网页、在表单字段中发布等。
SOAP 提供了类似的功能，但所有事情都是通过来回发送 XML 块来完成的。SOAP 的另一个关键组件是 WSDL，它是一个 XML 文档，描述了支持的功能和数据元素。WSDL 可用于以编程方式“发现”支持哪些功能以及生成编程代码存根。
SOAP 的问题在于它与 HTTP 堆栈背后的理想相冲突。任何中间件都应该能够在不了解请求或响应的内容的情况下处理 HTTP 请求，但是例如，常规的 HTTP 缓存服务器在不知道 SOAP 内容的哪些部分对缓存很重要的情况下将无法处理 SOAP 请求。SOAP 只是使用 HTTP 作为它自己的通信协议的包装器，就像代理一样。
我认为这很容易解释。拜托，欢迎任何人纠正我或添加到此。
SOAP 是断开系统（如互联网）用来交换信息/数据的消息格式。它处理来回传输的 XML 消息。
Web 服务传输或接收 SOAP 消息。它们的工作方式不同，具体取决于它们所用的语言。
REST 是一种用于设计网络应用程序的架构风格。这个想法是，不是使用复杂的机制，如 CORBA、RPC 或 SOAP 来连接机器，而是使用简单的 HTTP 在机器之间进行调用。
SOAP——“简单对象访问协议”
SOAP只是在 Internet 上传输消息或少量信息。SOAP消息采用XML格式，通常以控制HTTP的方式发送。
REST – “代表性状态转移”
REST是在粉丝和服务器之间接收和接收信息的基本过程，它没有明确定义许多标准。您可以以JSON、XML甚至纯文本的形式发送和接受信息。与SOAP相比，它是轻量级的。
基于 SOAP 的 Web 服务 简而言之，基于 SOAP 的服务模型将世界视为一个同等对等点的生态系统，这些对等点不能相互控制，但必须通过遵守已发布的合同来协同工作。它是混乱现实世界的有效模型，基于元数据的合同形成了 SOAP 服务接口。
我们仍然可以将 SOAP 与基于 XML 的远程过程调用联系起来，但是基于 SOAP 的 Web 服务技术已经成为一种灵活而强大的消息传递模型。
SOAP 假定所有系统都是独立的，并且没有任何系统对另一个内部功能和内部功能有任何了解。这样的系统能做的最多的事情就是互相发送消息，并希望它们会被采取行动。系统发布他们承诺遵守的合同，其他系统依赖这些合同与他们交换消息。
系统之间的合同统称为元数据，包括服务描述、支持的消息交换模式和管理服务质量的策略（服务可能需要加密、可靠交付等）。反过来，服务描述是详细的系统将发送和接收的数据（消息文档）的规范。文档使用 XML 描述语言（如 XML Schema Definition）进行描述。只要所有系统都遵守其发布的合同，它们就可以互操作，并且系统内部的更改永远不会影响任何其他系统。每个系统都负责将自己的内部实现与合同进行转换
REST - 具象状态转移。物理协议是 HTTP。基本上，REST 是 Web 上所有可以通过 URL 唯一标识的不同资源。可以对这些资源执行的所有操作都可以通过一组有限的动词（“CRUD”动词）来描述，这些动词又映射到 HTTP 动词。
与 SOAP 相比，REST 的“重量级”要小得多。