SOAP 与 XML-RPC 或 REST 的性能比较
关于使用 XML-RPC 或 REST 的解决方案的简单性的争论很容易理解，也很难反驳。
我还经常听到这样的争论：SOAP 开销的增加可能会显着影响使用的带宽，甚至可能影响延迟。 我想看看量化影响的测试结果。 有人知道此类信息的良好来源吗？
The arguments about the simplicity of solutions using XML-RPC or REST are easy to understand and hard to argue with.
I have often also heard arguments that the increased overhead of SOAP may significantly impact used bandwidth and possibly even latency. I would like to see the results of a test that quantifies the impact. Any one know a good source for such information?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
SOAP 与 REST 速度的主要影响与线速无关，而是与缓存能力有关。 REST 建议使用 Web 语义，而不是尝试通过 XML 进行隧道传输，因此 RESTful Web 服务通常设计为正确使用缓存标头，因此它们可以与缓存代理甚至本地浏览器缓存等 Web 标准基础设施良好配合。 此外，使用网络语义意味着 ETag 和自动 zip 压缩等都是众所周知的提高效率的方法。
..现在你说你想要基准。 好吧，在 Google 的帮助下，我找到了 一个人的测试表明 REST 比 SOAP 快 4-6 倍，而另一个人论文也支持 REST。
The main impact in speed of SOAP vs. REST has not to do with wire speed, but with cachability. REST suggests using the web's semantics instead of trying to tunnel over it via XML, so RESTful web services are generally designed to correctly use cache headers, so they work well with the web's standard infrastructure like caching proxies and even local browser caches. Also, using the web's semantics means that things like ETags and automatic zip compression are well understood ways to increase efficiency.
..and now you say you want benchmarks. Well, with Google's help, I found one guy whose testing shows REST to be 4-6x faster than SOAP and another paper that also favors REST.
SOAP 和任何其他使用 XML 的协议通常会使您的消息变得相当臃肿 - 这可能是也可能不是问题，具体取决于上下文。
像 JSON 这样的东西会更紧凑，并且序列化/反序列化可能更快 - 但不要仅仅因为这个原因而使用它。 做你当时觉得有意义的事情，如果有问题就改变它。
任何通常使用 HTTP 的内容（除非它重用 HTTP 1.1 keepalive 连接，而许多实现并不这样做），都会为每个请求启动一个新的 TCP 连接； 这是非常糟糕的，尤其是在高延迟链路上。 HTTPS 更糟糕。 如果您有从一个发送方到一个接收方的大量短请求，请考虑如何消除这一开销。
对任何类型的 RPC（无论是 SOAP 还是其他东西）使用 HTTP 总是会产生这种开销。 其他 RPC 协议通常允许您保持连接打开。
SOAP and any other protocol which uses XML generally bloats your messages quite a bit - this may or may not be a problem depending on the context.
Something like JSON would be more compact and maybe faster to serialise / deserialise - but don't use it exclusively for that reason. Do whatever you feel makes sense at the time and change it if it's a problem.
Anything which uses HTTP typically (Unless it's reusing a HTTP 1.1 keepalive connection, which many implementations do not) starts up a new TCP connection for each request; this is quite bad, especially over high latency links. HTTPS is much worse. If you have a lot of short requests from one sender to one receiver, think about how you can take this overhead out.
Using HTTP for any kind of RPC (whether SOAP or something else) is always going to incur that overhead. Other RPC protocols generally allow you to keep a connection open.
REST 作为一种协议，没有定义任何形式的消息信封，而 SOAP 却有这个标准。
因此，尝试比较两者有点简单化，它们是苹果和橙子。
也就是说，一个 SOAP 信封（减去数据）只有几 k，因此如果您通过 SOAP 和 REST 检索序列化对象，速度上应该不会有任何明显的差异。
REST as a protocol does not define any form of message envelope, while SOAP does have this standard.
Therefore, it's somewhat simplistic to try and compare the two, they are apples and oranges.
That said, a SOAP envelope (minus the data) is only a few k, so there shouldn't be any noticeable difference in speed provided you are retrieving a serialized object via both SOAP and REST.
有一些与此相关的研究可能会为您提供有用的信息。 请参阅以下内容：
在 MSDN 论坛。
简而言之，大多数来源似乎都同意 SOAP 和 REST 对于通用数据的性能大致相同。 然而，一些结果似乎表明，对于二进制数据，REST 实际上可能性能较差。 有关详细信息，请参阅我链接的论坛中的链接。
There are a few studies which have been done regarding this which you might find informative. Please see the following:
There is also an (somewhat out of date) interesting performance conversation about the topic at the MSDN Forums.
In short - most of these sources seem to agree that SOAP and REST are roughly the same performance for general-purpose data. Some results, however, seem to indicate that with binary data, REST may actually be less performant. See the links in the forum I linked for more detail on this.
扩展“pjz”的答案。
如果您收到大量基于 SOAP 操作的 INFORMATION（get* 调用类型），目前无法缓存它们。 但是，如果您要使用 REST 实现这些相同的操作，则数据（取决于您的业务上下文）可能会被缓存，如上所述。 由于 SOAP 使用 POST 进行操作，因此它无法在服务器端缓存信息。
Expanding on "pjz" 's answer.
If you're getting a lot of INFORMATION(get* type of calls) based SOAP operations, currently there is no way you can cache them. But if you were to implement these same operations using REST, there is a possibility that the data(depends on your business context) can be cached, as mentioned above. Because SOAP uses POST for its operations, it cannot cache the information at the server side.
SOAP 肯定更慢。 有效负载明显更大，组装、传输、解析、验证和处理速度更慢。
SOAP is definitely slower. Payloads are significantly larger which are slower to assemble, transport, parse, validate and process.
我不知道基准测试问题有任何答案，但是，我对 SOAP 格式所知道的是，它确实有开销，但每个请求的开销不会增加：如果您有一个元素发送到 Web 服务，您有开销 + 1 个元素构造，如果您有 1000 个元素发送到 Web 服务，则有开销 + 1000 个元素构造。 当 XML 请求针对特定操作进行格式化时，会产生开销，但请求中的每个单独参数元素的格式都相同。
如果您坚持使用可重复的短数据突发（例如 500 个元素），那么速度应该是可以接受的。
I don't know of any answer to the benchmarking question, however, what I do know about the SOAP format is yes, it does have overhead, but that overhead does not increase per request: if you have one element sent to the web service, you have overhead + one element construction, and if you have 1000 elements sent to the web service, you have overhead + 1000 element construction. The overhead occurs as the XML request is formatted for the particular operation, but every individual argument element in the request is formatted the same.
If you stick to repeatable, short bursts of data (say, 500 elements), the speed should be acceptible.
我想这里的主要问题是如何比较 RPC 和 SOAP。
它们都提供相同的通信抽象方法，通过使用您操作的存根对象和返回的原始/复杂数据类型，而无需真正了解这一切在底层是如何处理的。
我总是更喜欢（JSON-）RPC，因为
尽管有一些理由您应该使用 SOAP，即如果您需要命名参数，而不是依赖于它们的正确顺序，
您可以从此 stackoverflow 问题
I guess the main question here is how compares RPC with SOAP.
they both serve the same approach of communication abstraction by having stub objects you operate with and primitive/complex data types you get back without really knowing how this all is handled underneath.
I would always prefer (JSON-)RPC because
although there are reasons you should use SOAP, i.e. if you need naming parameters instead of relying on their correct order
some more details you get from this stackoverflow question