我读过有关 SOAP 和 REST 作为 Web 服务通信协议之间差异的文章，但我认为 REST 优于 SOAP 的最大优势是：
REST 更具动态性，无需创建和更新 UDDI（通用描述，发现和集成）。
REST 不仅限于 XML 格式。 RESTful Web 服务可以发送纯文本 / JSON / XML。
但 SOAP 更加标准化（例如：安全性）。
那么，我在这些方面是否正确？
不幸的是，围绕 REST 存在很多错误信息和误解。不仅您的问题和@cmd的答案反映了这些问题，而且大多数问题和答案都与 Stack Overflow 上的主题相关。
SOAP 和 REST 无法直接比较，因为第一个是协议（或者至少是尝试），第二个是架构风格。这可能是其中混淆的原因之一，因为人们倾向于将 REST 称为非 SOAP 的任何 HTTP API。
推动一些事情并尝试建立比较，SOAP 和 REST 之间的主要区别在于客户端和服务器实现之间的耦合程度。 SOAP 客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合。客户端和服务器之间存在严格的合同，如果任何一方发生任何变化，预计一切都会中断。您需要在任何更改后不断更新，但更容易确定是否遵循合同。
REST 客户端更像是一个浏览器。它是一个通用客户端，知道如何使用协议和标准化方法，并且应用程序必须适合它。您不会通过创建额外的方法来违反协议标准，您可以利用标准方法并在媒体类型上使用它们创建操作。如果做得好，那么耦合就会减少，并且可以更优雅地处理更改。除了入口点和媒体类型之外，客户端应该输入没有 API 知识的 REST 服务。在 SOAP 中，客户端需要先前了解它将使用的所有内容，否则它甚至不会开始交互。此外，REST 客户端可以通过服务器本身提供的按需代码进行扩展，经典示例是用于驱动与客户端上的另一个服务的交互的 JavaScript 代码。
我认为这些是了解 REST 的关键点，以及它与 SOAP 的区别：
REST 与协议无关。它没有耦合到 HTTP。非常类似于您可以在网站上关注 ftp 链接，REST 应用程序可以使用任何具有标准化 URI 方案的协议。
REST 不是 CRUD 到 HTTP 方法的映射。阅读此答案以获得详细解释。
REST 与您正在使用的部分一样标准化。 HTTP 中的安全性和身份验证是标准化的，因此这是您在通过 HTTP 进行 REST 时使用的内容。
没有超媒体和HATEOAS， REST 不是 REST。这意味着客户端只知道入口点 URI，并且资源应该返回客户端应该遵循的链接。那些为 REST API 中可以执行的操作提供 URI 模式的精美文档生成器完全忽略了这一点。它们不仅记录了应该遵循标准的内容，而且当您这样做时，您将客户端耦合到 API 发展过程中的某个特定时刻，并且必须记录和应用 API 的任何更改，或者它会破裂。
REST 是 Web 本身的架构风格。当您输入 Stack Overflow 时，您知道用户，问题和答案是什么，您知道媒体类型，并且网站为您提供了指向它们的链接。 REST API 必须执行相同的操作。如果我们按照人们认为应该完成 REST 的方式设计 Web，而不是让主页上有问题和答案的链接，我们会有一个静态文档解释为了查看问题，你必须采用 URI stackoverflow.com/questions/<id> ，用 Question.id 替换 id 并将其粘贴到浏览器上。这是无稽之谈，但这就是许多人认为 REST 的含义。
最后一点不够强调。如果您的客户正在从文档中的模板构建 URI 而不是在资源表示中获取链接，那么这不是 REST。 REST 的作者 Roy Fielding 在这篇博文中明确表示： REST API 必须是超文本驱动的 。
考虑到上述情况，您将意识到虽然 REST 可能不仅限于 XML，但要使用任何其他格式正确执行，您必须设计并标准化链接的某些格式。超链接是 XML 中的标准，但不是 JSON 中的标准。有 JSON 的草案标准，比如HAL 。
最后，REST 并不适合所有人，并且证明这一点就是大多数人使用他们错误地称为 REST 的 HTTP API 很好地解决他们的问题，并且从不冒险。 REST 有时很难做到，特别是在开始阶段，但随着时间的推移，它可以在服务器端更容易进化，并且客户端可以适应变化。如果您需要快速轻松地完成某项工作，请不要担心 REST 是否正确。这可能不是你想要的。如果您需要一些必须在线保持数年甚至数十年的东西，那么 REST 就适合您。
REST与SOAP 不是一个正确的问题。
与SOAP不同， REST 不是协议。
REST是一种架构风格和基于网络的软件架构设计 。
REST概念称为资源。资源的表示必须是无状态的。它通过某种媒体类型表示。媒体类型的一些示例包括XML ， JSON和RDF 。资源由组件操纵。组件通过标准统一接口请求和操作资源。在 HTTP 的情况下，该接口由标准 HTTP 操作组成，例如GET ， PUT ， POST ， DELETE 。
@ Abdulaziz 的问题确实说明了REST和HTTP经常串联使用的事实。这主要是由于 HTTP 的简单性以及它与 RESTful 原则的非常自然的映射。
客户端 - 服务器通信
客户端 - 服务器架构具有非常明显的关注点分离。所有以 RESTful 样式构建的应用程序原则上也必须是客户端 - 服务器。
无状态
每个客户端对服务器的请求都要求完全表示其状态。服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态。因此，所有州必须保留在客户端上。
可缓存
可以使用高速缓存约束，从而使响应数据能够被标记为可高速缓存或不可高速缓存。标记为可缓存的任何数据都可以重用作对同一后续请求的响应。
统一界面
所有组件必须通过单一的统一接口进行交互。由于所有组件交互都通过此接口进行，因此与不同服务的交互非常简单。界面是一样的！这也意味着可以单独进行实现更改。这种变化不会影响基本的组件交互，因为统一的接口总是不变的。一个缺点是您遇到了界面。如果可以通过更改界面为特定服务提供优化，那么由于 REST 禁止此操作，您将失去运气。然而，从好的方面来看，REST 针对 Web 进行了优化，因此 REST 在 HTTP 上非常受欢迎！
上述概念表示 REST 的定义特征，并将 REST 架构与 Web 服务等其他架构区分开来。值得注意的是，REST 服务是一种 Web 服务，但 Web 服务不一定是 REST 服务。
有关REST和上述子弹的更多详细信息，请参阅有关REST 设计原则的博客文章 。
编辑： 根据评论更新内容
SOAP（ 简单对象访问协议 ）和 REST（ 表示状态转移 ）都很漂亮。所以我不是在比较它们。相反，当我更喜欢使用 REST 和 SOAP 时，我试图描绘图片。
什么是有效载荷？
当通过因特网发送数据时，发送的每个单元包括头信息和发送的实际数据。标头标识数据包的源和目标， 而实际数据称为有效负载 。通常，有效载荷是代表应用程序携带的数据和目标系统接收的数据。
现在，例如，我必须发送一份电报 ，我们都知道电报的费用取决于某些字。
那么请告诉我下面提到的这两条消息，哪一条发送更便宜？
<name>Arin</name>要么
"name": "Arin"我知道你的答案将是第二个，虽然两个代表相同的消息，第二个是成本更便宜。
所以我想说， 通过网络以 JSON 格式发送数据比以 XML 格式发送有关负载更便宜 。
这是 REST over SOAP 的第一个好处或优点 。 SOAP 仅支持 XML，但 REST 支持不同的格式，如文本，JSON，XML 等。我们已经知道，如果我们使用 Json，那么我们肯定会在有效载荷方面做得更好。
现在，SOAP 支持唯一的 XML， 但它也有其优点。
真！怎么样？
SOAP 以三种方式依赖于 XML Envelope - 定义消息中的内容以及如何处理它。
一组数据类型的编码规则，最后是过程调用和响应的布局。
此信封通过传输（HTTP / HTTPS）发送，并执行 RPC（远程过程调用），并返回包含 XML 格式文档中信息的信封。
重要的一点是， SOAP 的一个优点是使用“通用” 传输，但REST 使用 HTTP / HTTPS 。 SOAP 几乎可以使用任何传输来发送请求，但 REST 不能。所以在这里我们获得了使用 SOAP 的优势。
正如我在上面的段落“REST 使用 HTTP / HTTPS” 中已经提到的那样，所以对这些词进行更深入的研究。
当我们讨论基于 HTTP 的 REST 时，所有应用 HTTP 的安全措施都是继承的，这称为传输级安全性 ，它只在邮件内部保护邮件但是一旦你在另一端发送它就不知道在到达处理数据的真实点之前需要经过多少个阶段。当然，所有这些阶段都可以使用与 HTTP 不同的东西。 所以休息并不完全安全，对吧？
但 SOAP 支持 SSL就像 REST 一样，它还支持 WS-Security ，它增加了一些企业安全功能。 WS-Security 可以防止消息的创建 。因此，对于传输级安全性，我们发现可以使用 WS-Security 阻止任何漏洞。
除此之外，由于REST 受到 HTTP 协议的限制，因此它的事务支持既不符合 ACID，也不能跨分布式跨国资源提供两阶段提交。
但 SOAP 全面支持基于 ACID 的短期事务事务管理和基于长期事务管理的基于补偿的事务管理。它还支持跨分布式资源的两阶段提交 。
我没有得出任何结论，但我更喜欢基于 SOAP 的 Web 服务，而安全性，事务等是主要关注点。
这是他们所说的 “Java EE 6 教程”。 当满足以下条件时，RESTful 设计可能是合适的 。看一看。
希望你喜欢阅读我的答案。