【问题标题】：Performance of SOAP vs. XML-RPC or RESTSOAP 与 XML-RPC 或 REST 的性能
【发布时间】：2010-09-11 12:23:12
【问题描述】：

关于使用 XML-RPC 或 REST 解决方案的简单性的争论很容易理解，也很难争论。

我还经常听到一些争论，即 SOAP 开销的增加可能会显着影响使用的带宽，甚至可能会影响延迟。我想看看量化影响的测试结果。有人知道此类信息的良好来源吗？

【问题讨论】：

标签： performance web-services rest soap xml-rpc

【解决方案1】：

REST 作为协议没有定义任何形式的消息信封，而 SOAP 确实有这个标准。

因此，尝试比较两者有点简单，它们是苹果对橘子。

也就是说，一个 SOAP 信封（减去数据）只有几 k，因此只要您通过 SOAP 和 REST 检索序列化对象，速度上应该不会有任何明显差异。

【讨论】：

我认为说 REST 没有定义消息信封是不诚实的。它说“使用 http 使用的东西”，这是 mime-types。
哦，真的吗？我想发送一个序列化的 C# 类，REST 协议的使用者如何知道如何从 mime 类型中解析它。
我认为当您尝试将 REST 视为一种协议时，问题就开始了。 REST 是一种可以使用 HTTP 协议的架构风格。
我将此问题解释为使用“REST”来指代（通常）“HTTP 上的 XML”或（不太常见的）“HTTP 上的自定义格式”，在这种情况下，比较是有效的问题。
@Tim Cooper - 提出 REST 一词的人以及大多数帮助传播 REST 的人都强烈反对这种说法。 [在 Wikipedia 上阅读有关 REST 的更多信息]（帮助推广）希望了解为什么 REST !== XML over HTTP。

【解决方案2】：

我不知道基准测试问题的任何答案，但是，我对 SOAP 格式的了解是肯定的，它确实有开销，但是每个请求的开销不会增加：如果您有一个元素发送到Web 服务，你有开销 + 一个元素构造，如果你有 1000 个元素发送到 Web 服务，你有开销 + 1000 个元素构造。当 XML 请求针对特定操作进行格式化时会产生开销，但请求中每个单独的参数元素的格式都相同。

如果您坚持使用可重复的短突发数据（例如 500 个元素），那么速度应该是可以接受的。

【讨论】：

【解决方案3】：

SOAP 与 REST 速度的主要影响与线速无关，而是与可缓存性有关。 REST 建议使用 Web 的语义，而不是尝试通过 XML 对其进行隧道传输，因此 RESTful Web 服务通常被设计为正确使用缓存标头，因此它们可以很好地与 Web 的标准基础设施（如缓存代理甚至本地浏览器缓存）配合使用。此外，使用网络语义意味着 ETags 和自动 zip 压缩之类的东西是众所周知的提高效率的方法。

..现在你说你想要基准测试。好吧，在 Google 的帮助下，我发现 one guy 的测试表明 REST 比 SOAP 快 4-6 倍，另一个 paper 也支持 REST。

【讨论】：

很好的答案 pjz，您是否意识到您的答案与 XML-RPC 或为什么它没有出现在要考虑的最佳选择中没有任何关系。
更新了“一个人”的链接learnosity.com/techblog/2008/03/cfmx-soap-vs-rest-benchmarks

【解决方案4】：

扩展 "pjz" 的答案。

如果您收到大量基于 INFORMATION（get* 调用类型）的 SOAP 操作，目前您无法缓存它们。但是，如果您要使用 REST 实现这些相同的操作，则可能会缓存数据（取决于您的业务上下文），如上所述。由于 SOAP 使用 POST 进行操作，它无法在服务器端缓存信息。

【讨论】：

【解决方案5】：

SOAP 和任何其他使用 XML 的协议通常会使您的消息膨胀很多 - 这可能是也可能不是问题，具体取决于上下文。

像 JSON 这样的东西会更紧凑，序列化/反序列化可能更快 - 但不要出于这个原因专门使用它。做任何你当时认为有意义的事情，如果有问题就改变它。

通常使用 HTTP 的任何东西（除非它重用 HTTP 1.1 keepalive 连接，许多实现不这样做）为每个请求启动一个新的 TCP 连接；这非常糟糕，尤其是在高延迟链接上。 HTTPS 更糟糕。如果您有很多从一个发送者到一个接收者的短请求，请考虑如何消除这些开销。

将 HTTP 用于任何类型的 RPC（无论是 SOAP 还是其他）总是会产生这种开销。其他 RPC 协议通常允许您保持连接打开。

【讨论】：

【解决方案6】：

SOAP 肯定更慢。有效负载明显较大，组装、传输、解析、验证和处理速度较慢。

【讨论】：

【解决方案7】：

已经完成了一些关于此的研究，您可能会发现这些研究提供了丰富的信息。请参阅以下内容：

MSDN Forums 上还有一个（有点过时的）有趣的性能对话。

简而言之，这些来源中的大多数似乎都同意 SOAP 和 REST 对于通用数据的性能大致相同。然而，一些结果似乎表明，对于二进制数据，REST 实际上可能性能较差。有关更多详细信息，请参阅我链接的论坛中的链接。

【讨论】：

【解决方案8】：

我想这里的主要问题是如何比较 RPC 和 SOAP。

它们都提供相同的通信抽象方法，通过使用您操作的存根对象和返回的原始/复杂数据类型，而无需真正知道这一切是如何在底层处理的。

我总是更喜欢 (JSON-)RPC，因为

它很轻量级
所有编程语言都有很多出色的实现
易于学习/使用/创建
速度很快（尤其是 JSON）

虽然您应该使用 SOAP 是有原因的，例如，如果您需要命名参数而不是依赖于它们的正确顺序

您可以从这个 stackoverflow question 获得更多详细信息

【讨论】：