SOAP 和 REST 不能直接比较，因为前者是一种协议（或至少试图如此），而后者是一种架构风格。这可能是造成混淆的原因之一，因为人们倾向于将 REST
称为任何不是 SOAP 的 HTTP API。

稍微推动一下并尝试建立一个比较，SOAP 和 REST 之间的主要区别在于客户端和服务器实现之间的耦合程度。SOAP
客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合。客户端和服务器之间有一个严格的合同，如果任何一方改变任何东西，一切都会被打破。您需要在任何更改后不断更新，但更容易确定是否遵守了合同。

REST
客户端更像是浏览器。它是一个知道如何使用协议和标准化方法的通用客户端，应用程序必须适应其中。您不会通过创建额外的方法来违反协议标准，您可以利用标准方法并在您的媒体类型上使用它们创建操作。如果做得好，耦合就会减少，并且可以更优雅地处理更改。除了入口点和媒体类型外，客户端应该在对
API 零知识的情况下进入 REST 服务。在 SOAP
中，客户端需要事先了解它将使用的所有内容，否则它甚至不会开始交互。此外，可以通过服务器本身提供的按需代码来扩展 REST 客户端，

我认为这些是理解 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 应该完成的方式设计网络，而不是拥有一个带有问题和答案链接的主页，我们会有一个静态文档解释，为了查看问题，您必须获取 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 适合您。