具象状态传输 (REST) 和简单对象访问协议 (SOAP)
Posted
技术标签:
【中文标题】具象状态传输 (REST) 和简单对象访问协议 (SOAP)【英文标题】：Representational state transfer (REST) and Simple Object Access Protocol (SOAP) 【发布时间】：2010-09-17 14:48:43 【问题描述】：谁能用简单的英语解释一下REST 和SOAP 是什么？ Web 服务是如何工作的？
【问题讨论】：
您必须阅读此PDF 以了解 REST 和 SOAP Web 服务。 你可以查看这个博客javapapers.com/web-service/rest-vs-soap 我可以推荐阅读菲尔丁关于 REST 主题的论文吗：ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm SOAP or REST for Web Services?的可能重复 @PhilipCouling 我不会把任何博士论文称为简单的英语...... 【参考方案1】：我认为这很容易解释。拜托，欢迎任何人纠正我或添加到此。
SOAP 是一种消息格式，被断开连接的系统（如互联网）用来交换信息/数据。它处理来回传输的 XML 消息。
Web 服务传输或接收 SOAP 消息。它们的工作方式因所用语言而异。
【讨论】：
详细说明“它们的工作方式不同”是什么意思。 SOAP 通常用作使用不同或未知技术编写的不同系统使用具有明确定义参数的通用可理解语言进行对话的一种方式。 Web 服务的工作方式因编写的语言而异。只是一个不重要的额外细节。 好的，我不确定您是否暗示存在阻碍互操作性的问题。【参考方案2】：许多大玩家都使用这两种方法。这是一个偏好问题。我的首选是 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 通常最好与Resource Oriented Architecture (ROA) 一起使用。在这种思维模式下，一切都是资源，您将在这些资源上进行操作。 只要您的编程语言具有 HTTP 库（大多数情况下），您就可以非常轻松地使用 REST HTTP 协议。 二进制数据或二进制资源可以根据他们的请求简单地交付。有endless debates on REST vs SOAP on google。
My favorite is this one。 2013 年 11 月 27 日更新：Paul Prescod 的网站似乎已下线，这篇文章不再可用，但可以在 Wayback Machine 或CiteSeerX 找到 PDF 文件。
【讨论】：
REST 与 HTTP 无关（它独立于协议），并且 XML 可以在 RESTful 架构中使用。 GET/POST/PUT/DELETE 只是正确使用 HTTP - REST 是必需的，但还不够。 REST 客户端如何知道他可能使用哪些方法和类型？在 SOAP 中，有许多工具可以从中生成类和方法的 WSDL。 @jlp：正确使用暴露的 REST 接口取决于 REST 客户端开发人员。 REST 只是说“使用统一接口”。由于 HTTP 接口 [GET, POST, PUT, DELETE, (UPDATE, HEAD)] 成为网络的“统一接口”，我认为 REST（在网络上）在某种程度上依赖于 HTTP！ @aehlke REST 非常依赖 HTTP。否则说是疯了。 REST 方法是通过 HTTP RFC（由 W3C TAG）明确定义的。除了加州大学欧文分校的 Roy Fielding 的博士论文之外，没有其他规范。见：en.wikipedia.org/wiki/Representational_state_transfer【参考方案3】：我喜欢 Brian R. Bondy 的回答。我只是想补充一点，***提供了对REST 的清晰描述。这篇文章将它与 SOAP 区分开来。
REST 是状态信息的交换，尽可能简单地完成。
SOAP 是一种使用 XML 的消息协议。
许多人从 SOAP 迁移到 REST 的主要原因之一是与基于 SOAP 的 Web 服务相关的 WS-*（称为 WS splat）标准非常复杂。有关规格列表，请参阅wikipedia。这些规范中的每一个都非常复杂。
编辑：由于某种原因，链接显示不正确。休息 = http://en.wikipedia.org/wiki/REST
WS-* = http://en.wikipedia.org/wiki/WS-*
【讨论】：
SOAP 不是协议。 SOAP 是关于编码的。 SOAP 用于多种协议：JMS、http、... @koppor 你的意思不是它代表“简单对象访问协议”吗？另外，你知道什么是协议吗？协议基本上是一组关于两个或多个事物应该如何通信的规则，这正是 SOAP 的用途，一种标准的通信方式。 @Demizey 您指的是 SOAP 的最新版本，即 1.2 吗？ w3.org/TR/soap12-part1“SOAP”现在独立存在，因为实际上它不用作协议。 “SOAP 1.2 不会拼出首字母缩写词。” (w3.org/TR/2007/REC-soap12-part0-20070427/#L4697) 您是否了解 Web 服务堆栈的各层，例如《Web 服务平台架构：Soap、Wsdl、Ws-Policy、Ws-Addressing、Ws-Bpel、Ws-Reliable Messaging ， 和更多”？传输层通信通过 HTTP、SMTP、RMI/IIOP、JMS 或其他方式完成。 SOAP 用于消息传递层 沿着 SOAP 连接线，许多中介可能位于中间。这是由 SOAP 处理模型实现的，该模型区分最终的 SOAP 接收器和零个或多个 SOAP 中介。传输协议可能会在两者之间发生变化。 SOAP 消息路径还支持 EAI 模式的透明实现 (eaipatterns.com) 它仍然是一个消息传递协议。【参考方案4】：SOAP 和 REST 都是指不同系统相互通信的方式。
REST 使用类似于您的浏览器与 Web 服务器的通信的技术来执行此操作：使用 GET 请求网页、在表单字段中发布等。
SOAP 提供了类似的功能，但所有事情都是通过来回发送 XML 块来完成的。 SOAP 的另一个关键组件是 WSDL，它是一个 XML 文档，描述了支持的功能和数据元素。 WSDL 可用于以编程方式“发现”支持哪些功能以及生成编程代码存根。
【讨论】：
这与 REST 无关，只是“正确使用 HTTP” HTTP 本身就是 RESTful 系统的最佳示例。 @pbreitenbach 不，HTTP 不是，它基本上没有超媒体的概念。但是带有超链接和表单的 html 是一个 RESTful 系统。实际上，它是 REST“规范”的原型 SOAP 不会强制您使用 XML 编码。仅当服务提供互操作性时才使用 XML 编码。在内部，POJO 可以在没有 XML 编码的情况下发送。【参考方案5】：SOAP 的问题在于它与 HTTP 堆栈背后的理想相冲突。任何中间件都应该能够在不了解请求或响应的内容的情况下处理 HTTP 请求，但是例如，常规的 HTTP 缓存服务器在不知道 SOAP 内容的哪些部分对缓存很重要的情况下将无法处理 SOAP 请求。 SOAP 只是使用 HTTP 作为其自己的通信协议的包装器，就像代理一样。
【讨论】：
这与理想背道而驰，而我们才刚刚注意到这一点。它从 1998 年左右就已经存在了，我们只是在接受它。该死的，我们是愚蠢的！ 没有约翰，“我们”作为知情的网络开发者社区，一直都知道。只有那些速度慢的，以及那些从 CS 学校毕业而没有接受过适当教育的人才刚刚起步。 “我们”并不都是 Web 开发人员。我们中的一些人只是试图以最好的方式完成工作，而不是关心我们是否“没有充分利用网络的全部潜力”。 "stupif" 总结了一下，是的。【参考方案6】：关于 SOAP 和 REST 的简单解释
SOAP - “简单对象访问协议”
SOAP 是一种通过 Internet 传输消息或少量信息的方法。 SOAP 消息采用 XML 格式，通常使用 HTTP（超文本传输协议）发送。
Rest - 表征状态转移
Rest 是一种在客户端和服务器之间发送和接收数据的简单方法，它没有定义很多标准。您可以以 JSON、XML 甚至纯文本的形式发送和接收数据。与 SOAP 相比，它的重量较轻。
【讨论】：
SOAP 不仅仅是在信封中发送数据。但是，它主要用于将 BLOB 发送到服务器，而忽略 SOAP 还提供的任何功能。所以基本上，大多数人使用带有标准信封的 SOAP，如 REST。 （SOAP 是过度工程的一个很好的例子） SOAP 绝不会强制人们使用 HTTP 或 XML。 HTTP 和 XML 是 WS-I 中为互操作性而定义的东西，但也可以通过 JMS 发送 POJO。问题是，程序员不需要关心：服务总线管理传输和编码。 对于每一个复杂的问题，都有一个清晰、简单和错误的答案。 - H。 L.门肯 这个例子太棒了！ 继续阅读。虽然这个答案很有趣@Pavel 下面的答案要完整得多。【参考方案7】：这是你能找到的最简单的解释。
本文采用一对夫妻的叙述方式，丈夫向妻子解释 REST，纯粹是外行。必读！
how-i-explained-rest-to-my-wife（原链接）how-i-explained-rest-to-my-wife（2013-07-19工作链接）
【讨论】：
关于多态的部分很漂亮。【参考方案8】：休息
我了解 REST 的主要思想非常简单。我们多年来一直使用网络浏览器，并且我们已经看到网站是多么简单、灵活、执行等等。 HTML 站点使用超链接和表单作为用户交互的主要方式。他们的主要目标是让我们这些客户只知道那些我们可以在当前状态下使用的链接。 REST 只是说“为什么不使用相同的原则来驱动计算机而不是人类客户端通过我们的应用程序？”将其与 WWW 基础架构的强大功能相结合，您将获得构建出色分布式应用程序的杀手级工具。
另一种可能的解释是针对具有数学思维的人。每个应用程序基本上都是一个状态机，其业务逻辑操作是状态转换。 REST 的想法是将每个转换映射到对资源的某个请求，并为客户端提供表示当前状态下可用转换的链接。因此，它通过表示和链接对状态机进行建模。这就是为什么它被称为 REpresentational State Transfer。
令人惊讶的是，所有答案似乎都集中在消息格式或 HTTP 动词的使用上。事实上，消息格式根本不重要，只要服务开发人员记录在案，REST 可以使用任何一种格式。 HTTP 动词仅使服务成为 CRUD 服务，但还不是 RESTful。真正将服务转变为 REST 服务的是与数据一起嵌入到服务器响应中的超链接（也称为超媒体控件），它们的数量必须足以让任何客户端从这些链接中选择下一个操作。
不幸的是，除了Roy Fielding's thesis 之外，很难在 Web 上找到有关 REST 的正确信息。 （他是派生 REST 的人）。我会推荐'REST in Practice' book，因为它提供了有关如何从 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.NET Web API 这样的优秀框架，但没有可以自动生成客户端代理的工具。没有像“添加 Web 服务引用”或“添加 WCF 服务引用”这样的东西。必须手动编写所有序列化和服务查询代码。伙计，那是很多样板代码。我认为 REST 开发需要类似于 WSDL 的东西以及每个开发平台的工具实现。事实上，似乎有一个很好的理由：WADL 或 WSDL 2.0，但似乎这两个标准都没有得到很好的支持。
更新（2016 年 1 月）
现在有一个wide variety of tools 用于 REST API 定义。我个人偏好目前是RAML。
Web 服务的工作原理
嗯，这是一个过于宽泛的问题，因为它取决于特定 Web 服务中使用的架构和技术。但一般来说，Web 服务只是 Web 中可以接受来自客户端的请求并返回响应的一些应用程序。它向 Web 公开，因此它是一个 web 服务，并且通常 24/7 可用，这就是它是一个 service 的原因。当然，它为客户解决了一些问题（否则为什么有人会使用 Web 服务）。
【讨论】：
这应该是迄今为止最受好评的答案！我有幽默感，但当 *** 上的喜剧回答胜过深思熟虑的回答时，我感到很沮丧。 @TomHall 我想这种情况有点特定于 REST - RPC 讨论，而不仅仅是 SO。我想这就是我们没有为 REST 客户端提供合理工具的原因。至少在 .NET 上，已证明实现 REST 服务客户端比生成 SOAP 服务引用要困难得多。必须手动编写代理类。出于某种原因，人们认为 REST 好像根本没有规则，而最初的想法恰恰相反，对架构施加了更多限制。我希望社区了解 REST - 然后我们可以期待更好的工具和采用。 @PavelGatilov 这个答案很棒。我已经阅读了其他 REST 解释，但从未“明白”驱动原则是可能的状态转换是响应的一部分。您花时间反思自己的经历并承认困难这一事实对我们每个人来说也很有价值。 优秀的答案。我想知道现在 REST-I 需要多长时间才能开发出来，因为它开始看起来越来越像 SOAP，而 RAML、Swagger 和 WADL 正在为成为 REST 的事实标准而苦苦挣扎。在开发一些相当敏感和复杂的金融系统时，我发现与 SOAP 相比，缺少 REST 工具是一个主要的痛点。正确使用时，REST 和 SOAP 都很棒。我的祖父总是说你可以用螺丝刀敲钉子，但它不会那么好用。这里同样适用。工作心态的正确工具不是我的方式是唯一的方式。\ 哦，我也喜欢 RAML，我更喜欢自上而下的开发，我发现 REST 最令人不安的一件事是缺乏结构化的自上而下的方法。我喜欢三思而后行。【参考方案9】：好吧，我将从第二个问题开始：什么是 Web 服务？，原因很明显。
WebServices 本质上是公开某些功能或数据的逻辑片段（您可能模糊地称为方法）。客户端实现（从技术上讲，消费就是这个词）只需要知道方法要接受的参数是什么以及它是什么类型的数据会回来（如果有的话）。
以下链接以极其清晰的方式说明了REST和SOAP。
REST vs SOAP
如果您还想知道何时选择什么（REST 或 SOAP），那就更有理由去经历它！
【讨论】：
【参考方案10】：REST 是一种用于设计网络应用程序的架构风格。这个想法是，不是使用复杂的机制，如 CORBA、RPC 或 SOAP 来连接机器，而是使用简单的 HTTP 在机器之间进行调用。
【讨论】：
【参考方案11】：基于 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
【讨论】：
-1 您说的几乎所有内容都不正确。 SOAP 不包含描述。 WSDL 可以。 WSDL 是一种 XML 格式——它不会在任何协议上“运行”。 SOAP 不需要中间件。 REST 不是“第二代 Web 服务”。 WADL不是标准。见en.wikipedia.org/wiki/Web_Application_Description_Language。【参考方案12】：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 设计原则 的博客 post。
【讨论】：
只是认为请求 RESTful 资源并接收响应，其中包含指向 WSDL 的链接，描述在当前状态下对该资源可用的操作，这完全是 HATEOAS。虽然我猜想 RESTful SOAP Web 服务有点像跳过 RMM 级别 3 并直接进入级别 4。:) 这是反映它不是/或不是 REST 和 SOAP 的最佳答案。 +1 指出 REST 是一种 style。【参考方案13】：SOAP webservices 和 REST webservices 都可以使用 HTTP 协议和其他协议（只是提到 SOAP 可以是 REST 的底层协议）。我将只讨论与 HTTP 协议相关的 SOAP 和 REST，因为这是它们最常用的用法。
肥皂
SOAP（“简单”对象访问协议）是一个协议（和一个W3C standard）。它定义了如何创建、发送和处理 SOAP 消息。
SOAP 消息是具有特定结构的 XML 文档：它们包含一个包含标头和正文部分的信封。正文包含 XML 格式的实际数据——我们要发送。有two encoding styles，但是we usually choose literal，意思是我们的应用或者它的SOAP驱动做数据的XML序列化和反序列化。
SOAP 消息作为带有 SOAP+XML MIME 子类型的 HTTP 消息传播。这些 HTTP 消息可以是多部分的，因此我们可以选择将文件附加到 SOAP 消息。
显然我们使用客户端-服务器架构，因此 SOAP 客户端将请求发送到 SOAP 网络服务，而服务将响应发送回客户端。大多数 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（代表性状态转移）是一种架构风格，在 Roy Fielding 的dissertation 中进行了描述。它不像 SOAP 那样关心协议。它从没有约束的空架构样式开始，并一一定义了 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 服务维护公共数据 - 此后的资源状态 - 并将其提供给客户端。 无状态 - 缩写的“状态转移”部分：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 有一些specifications，例如具有相同路径但不同查询的 URL 不完全相同，或者路径部分应包含 URL 的分层数据，而查询部分应包含非分层数据。这些是如何通过 REST 创建 URL 的基础知识。顺便提一句。 URL 结构只对服务开发人员很重要，真正的 REST 客户端与它无关。另一个常见问题是 API 版本控制，这是一个简单的问题，因为根据 Fielding 的说法，资源唯一不变的就是语义。如果语义发生变化，那么您可以添加新的版本号。您可以使用经典的3 number versioning 并仅将主号码添加到 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 方法的 specification 很重要。例如 GET 表示检索由请求 URL 标识的信息，DELETE 表示要求服务器删除由给定 URL 标识的资源，等等...... HTTP 状态代码也有一个specification，例如 200 表示成功， 201 表示已创建新资源，404 表示在服务器上未找到请求的资源等...使用现有标准是 REST 的重要组成部分。
超媒体作为应用程序状态的引擎（以下称为 HATEOAS）——超媒体是一种可以包含超链接的媒体类型。通过网络，我们跟随链接 - 由超媒体格式（通常是 HTML）描述 - 来实现目标，而不是在地址栏中输入 URL。 REST 遵循相同的概念，服务发送的表示可以包含超链接。我们使用这些超链接向服务发送请求。通过响应，我们得到数据（可能还有更多链接），我们可以使用这些数据来构建新的客户端状态，等等……这就是为什么超媒体是应用程序状态（客户端状态）的引擎。您可能想知道客户如何识别和跟踪超链接？对人类来说，这很简单，我们阅读链接的标题，也许填写输入字段，然后单击一下。通过机器，我们必须通过 RDF（JSON-LD 和 Hydra）或超媒体特定解决方案（例如 IANA link relations 和 vendor specific MIME types HAL+JSON）为链接添加语义。有很多机器可读的XML 和JSON hypermedia formats，只是其中的一小部分：
XHTML ATOM+XML RDF+XML HAL+XML HAL+JSON JSON-LD RDF+JSON Siren Collection+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 约束：
客户端-服务器架构 - 始终 无状态 - possible 缓存 - possible 统一界面 - 从不 分层系统 - never 按需编码（可选）- 可能【讨论】：
【参考方案14】：SOAP – “简单对象访问协议”
SOAP 是一种在 Internet 上传输消息或少量信息的轻微方式。 SOAP 消息采用 XML 格式，通常通过控制 HTTP 发送。
REST – “代表性状态转移”
REST 是在粉丝和服务器之间的偶然性和接收信息的基本过程，它没有明确定义的许多标准。您可以发送和接受 JSON、XML 甚至纯文本形式的信息。与 SOAP 相比，它是轻量级的。
【讨论】：
以上是关于具象状态传输 (REST) 和简单对象访问协议 (SOAP)的主要内容，如果未能解决你的问题，请参考以下文章