为什么更喜欢 REST 而不是 SOAP？答案

【问题标题】：Why prefer REST over SOAP?为什么更喜欢 REST 而不是 SOAP？
【发布时间】：2010-11-24 11:57:59
【问题描述】：

如果我需要一个 Web 服务来来回传递一个复杂的对象，我是否有理由更喜欢 SOAP 而不是 REST？以下是可能的 SOAP 消息的示例：

<soap:Envelope>
  <soap:Header>
    <Credentials>
      <User>Joe</User>
      <Password>abc123</Password>
    </Credentials>
  </soap:Header>
  <soap:Body>
    <MyComplexBusinessObject>
      <Search>
        <First>Joe</First>
        <Last>Smith</Last>
      </Search>
      ...
      ...
    </MyComplexBusinessObject>
  </soap:Body>
</soap:Envelope>

使用 REST，我会要求客户端发布以下 xml 并使用基本身份验证进行身份验证：

<MyComplexBusinessObject>
  <Search>
    <First>Joe</First>
    <Last>Smith</Last>
  </Search>
  ...
  ...
</MyComplexBusinessObject>

SOAP 消息稍微复杂一些，但并不复杂。它们仍然都是 XML，但是 SOAP 带有 WSDL，并且大多数编程环境都会为您生成代理类。但是，与我交谈的大多数人都说我应该改用 REST，因为它更易于使用。但我不明白 SOAP 是如何更难使用的。

我错过了什么吗？

【问题讨论】：

为什么 XML 才是重点。 JSON 会更整洁（从编程的角度来看）并且更紧凑。 [{'First':'Joe','Last':'Smith'},...]
你将如何传递一个复杂的对象？当然我可以使用 JSON，但这还不足以证明放弃 SOAP 转而使用 REST 是合理的。该对象可能包含嵌套字段，并且可能无法很好地转换为 URL。
实际上，对于这种情况，更好的匹配是使用标准 POST 变量发布到/search； 1=Joe,Smith&2=John,Citizen&... 例如。如果您想要的不仅仅是搜索，那么您就来错了地方 - SOAP 可能会在一个 URL 上获取所有内容，但 REST 不是这样的 - 每件事一个 URL（如果您可以这样做 /search/joe+smith或类似的东西会更好）。

标签： web-services rest soap

【解决方案1】：

“来回传递复杂对象”的第一个要求限制了您的架构，以消除 REST 的许多好处。 SOAP 是为访问远程对象而设计的，而 REST 不是。 REST 支持像 text/plain 这样简单的媒体类型传递，这比处理对象要原始得多。

如果您还没有看过它，this 问题及其答案涵盖了大多数 REST 与 SOAP 问题。

【讨论】：

大多数 RESTful 服务可以描述为“来回传递复杂对象”，也就是表示状态传输。而且几乎没有人使用text/plain。 REST 更面向文档，而 SOAP 更类似于 RPC。
@J.F.Sebastian 大多数声称是 RESTful 的服务实际上并非如此。在客户端和服务器之间传递一个对象意味着共享一个类型以及某些语义，这些都没有在消息中显式声明。这违反了 REST 的约束。

【解决方案2】：

REST 的一个主要优点是，您只需调用和使用一个浏览器和一个 HTTP 堆栈即可调用和使用它 - 几乎所有设备和机器都有。因此，如果您的主要目标是易用性和覆盖范围 - 请使用 REST。

SOAP 的主要好处之一是您拥有一个 WSDL 服务描述，并且您几乎可以自动发现该服务，并从该服务描述生成一个可用的客户端代理（生成服务调用、必要的数据类型）方法等）。

因此，如果可发现性和严格、正式的服务描述对您来说更重要，请使用 SOAP（缺点是您需要一个成熟的 SOAP 客户端来调用您的服务 - 您的 Web 浏览器是不够的）。

SOAP 并不难使用——但就可用性而言，它并没有那么“普遍”——任何浏览器都可以调用 REST 服务并获得答案——但是它需要解析和解释该响应。 SOAP 获得了不错的数据结构，但您需要一个 SOAP 客户端。

【讨论】：

但是您真的需要一个成熟的 SOAP 客户端吗？我不能只复制消息，填写空白，然后将其发布到端点吗？那不是几乎与 REST 客户端“相同”吗？我并不是要让它听起来像我反对 REST——我想被说服。
@marc_s，“但是它需要解析和解释该响应”，使用 JavaScript 使用 COD 不会解决这个问题吗？
@Ashley：据我所知，如果您想与 SOAP 服务通信，您需要一个 SOAP 客户端。我认为您不能“仅发布”到该 URL（无论如何，我自己从未尝试过）
@Anders：在一定程度上可能——但 REST 服务（至少在今天）通常没有机器可发现的描述它在方法/URL/数据方面提供的内容。作为程序员，您需要以某种方式知道，例如通过阅读、理解和遵循一些文档。
@Darrel Miller：你有任何链接来说明这一点吗？看看有趣...

【解决方案3】：

我将 SOAP 和 REST 视为正交 API，旨在做不同的事情。

SOAP 基本上是一个花哨的 RPC，所以如果你想向服务器发送一个计算请求并返回结果，你可以使用 SOAP。如果它是本地的，它将是对对象实例的方法调用。

REST 是一种使用统一 API 创建、检索、更新和删除远程对象的方法，而不是 POO 意义上的。如果它是本地的，那就像处理文件一样。

所以他们实际上响应了不同的需求。你可以私下化一个人去做另一个人的工作，但你会破坏意义。

【讨论】：

【解决方案4】：

如果您同时开发服务和客户端，那么使用 SOAP 就像 REST 一样简单（实际上更容易）。

如果满足这些条件，您可能更喜欢 SOAP 而不是 REST：

整个服务 API 很复杂，而不仅仅是一个对象。
服务在相对较小的网络中使用，性能不是重要要求。
您决定花费最少的时间来开发服务和 API 文档。

【讨论】：