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

我也经常听到这样的论点，即SOAP开销增加可能会严重影响已使用的带宽，甚至可能会影响延迟。我希望看到量化影响的测试结果。有人知道这种信息的好来源吗？

解决方案

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

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

就是说，SOAP信封(减去数据)只有几k，因此，如果我们同时通过SOAP和REST检索序列化的对象，那么速度应该不会有任何明显的差异。

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

如果坚持使用可重复的短数据突发(例如500个元素)，则速度应该可以接受。

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

..现在我们说想要基准测试。好吧，在Google的帮助下，我发现一个人的测试表明REST比SOAP快4-6倍，而另一篇论文也支持REST。

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

SOAP和其他使用XML的其他协议通常会使消息大量膨胀，根据上下文的不同，这可能是问题，也可能不是问题。

诸如JSON之类的东西会更紧凑，并且序列化/反序列化的速度可能更快，但由于这个原因，请不要专门使用它。做出我们当时认为有意义的事情，并在出现问题时进行更改。

通常使用HTTP的所有内容(除非重新使用HTTP 1.1 keepalive连接，许多实现都没有使用)会为每个请求启动一个新的TCP连接。这是非常糟糕的，尤其是在高延迟链接上。 HTTPS更糟。如果我们从一个发送方到一个接收方有很多短请求，请考虑如何减少此开销。

将HTTP用于任何类型的RPC(无论是SOAP还是其他)，总是会产生开销。其他RPC协议通常允许我们保持连接打开。

SOAP肯定慢一些。有效载荷明显较大，组装，运输，解析，验证和处理速度较慢。