关于使用 XML-RPC 或 REST 解决方案的简单性的争论很容易理解，也很难争论。
我还经常听到一些争论，即 SOAP 开销的增加可能会显着影响使用的带宽，甚至可能会影响延迟。我想看看量化影响的测试结果。有人知道此类信息的良好来源吗？
Bradley Harris
问问题
28114 次
8 回答
63
SOAP 与 REST 速度的主要影响与线速无关，而与可缓存性有关。REST 建议使用 Web 的语义而不是尝试通过 XML 对其进行隧道传输，因此 RESTful Web 服务通常被设计为正确使用缓存标头，因此它们可以很好地与 Web 的标准基础设施（如缓存代理甚至本地浏览器缓存）配合使用。此外，使用 Web 的语义意味着 ETags 和自动 zip 压缩之类的东西是很好理解的提高效率的方法。
..现在你说你想要基准。好吧，在 Google 的帮助下，我找到了一个人，他的测试表明 REST 比 SOAP 快 4-6 倍，而另一篇论文也支持 REST。
于 2008-09-20T01:25:47.293 回答
19
REST 作为协议没有定义任何形式的消息信封，而 SOAP 确实有这个标准。
因此，尝试比较两者有点简单，它们是苹果对橘子。
也就是说，一个 SOAP 信封（减去数据）只有几 k，因此只要您通过 SOAP 和 REST 检索序列化对象，速度上应该不会有任何明显差异。
于 2008-09-20T00:31:53.240 回答
8
SOAP 和任何其他使用 XML 的协议通常会使您的消息膨胀很多——这可能是也可能不是问题，具体取决于上下文。
像 JSON 这样的东西会更紧凑，序列化/反序列化可能更快 - 但不要出于这个原因专门使用它。做任何你当时觉得有意义的事情，如果有问题就改变它。
任何通常使用 HTTP 的东西（除非它重用 HTTP 1.1 keepalive 连接，许多实现不这样做）为每个请求启动一个新的 TCP 连接；这非常糟糕，尤其是在高延迟链接上。HTTPS 更糟糕。如果您有很多从一个发送者到一个接收者的短请求，请考虑如何消除这些开销。
将 HTTP 用于任何类型的 RPC（无论是 SOAP 还是其他）总是会产生这种开销。其他 RPC 协议通常允许您保持连接打开。
于 2008-09-20T07:53:41.680 回答
6
有一些关于这方面的研究，您可能会发现这些研究提供了丰富的信息。请参阅以下内容：
在MSDN 论坛上还有一个（有点过时的）有趣的关于该主题的性能对话。
简而言之 - 这些来源中的大多数似乎都同意 SOAP 和 REST 对于通用数据的性能大致相同。然而，一些结果似乎表明，对于二进制数据，REST 实际上可能性能较差。有关更多详细信息，请参阅我链接的论坛中的链接。
于 2012-11-30T18:57:32.740 回答
5
扩展 "pjz" 的答案。
如果您获得大量基于信息（get* 调用类型）的 SOAP 操作，那么目前您无法缓存它们。但是，如果您要使用 REST 实现这些相同的操作，则可能会缓存数据（取决于您的业务上下文），如上所述。因为 SOAP 使用 POST 进行操作，所以它不能在服务器端缓存信息。
于 2008-09-20T01:39:01.270 回答
4
SOAP 肯定更慢。有效负载要大得多，组装、传输、解析、验证和处理的速度较慢。
于 2009-07-04T07:09:01.010 回答
2
我不知道基准测试问题的任何答案，但是，我对 SOAP 格式的了解是肯定的，它确实有开销，但是每个请求的开销不会增加：如果您将一个元素发送到 Web 服务，你有开销 + 一个元素构造，如果你有 1000 个元素发送到 Web 服务，你有开销 + 1000 个元素构造。当 XML 请求针对特定操作进行格式化时会产生开销，但请求中的每个单独的参数元素的格式都是相同的。
如果您坚持使用可重复的短数据突发（例如 500 个元素），那么速度应该是可以接受的。
于 2008-09-20T00:32:46.873 回答
0
我想这里的主要问题是如何比较 RPC 和 SOAP。
它们都通过使用您操作的存根对象和您返回的原始/复杂数据类型来提供相同的通信抽象方法，而您却不知道这一切是如何在下面处理的。
我总是更喜欢（JSON-）RPC，因为
- 它很轻
- 所有编程语言都有很多很棒的实现
- 学习/使用/创建很简单
- 它很快（尤其是 JSON）
尽管您应该使用 SOAP 是有原因的，即如果您需要命名参数而不是依赖于它们的正确顺序
您从这个 stackoverflow问题中获得的更多详细信息
于 2014-04-03T08:04:38.580 回答