我阅读了一些已在此处发布的关于肥皂和休息的问题 我没有找到我正在寻找的答案。 我们有一个使用 Soap Web 服务构建的系统。 该系统的性能不是很好，正在讨论中 将所有 Soap Web 服务替换为 REST Web 服务。 有人认为 Rest 的性能更好。 我不知道这是不是真的。 （这是我的第一个问题） 假设这是真的，使用 REST而不是肥皂？ （我们会失去什么吗？）
提前致谢。
【问题讨论】：
标签： web-services performance rest soap
我绝对不是 SOAP 与 REST 的专家，但我知道的唯一性能差异是 SOAP 在发送/接收数据包时有很多开销，因为它是基于 XML 的，需要 SOAP 标头等. REST 使用 URL + 查询字符串来发出请求，因此不会通过网络发送那么多 kB。
我敢肯定这里还有其他人可以给你更好和更详细的答案，但至少我试过了；）
【讨论】：
SOAP 需要解析 XML 消息，并且需要发送和接收所有
REST 通常使用更简洁且易于解析的内容，例如 JSON。
但在实践中，差异并没有那么大。
从 XML 构建 DOM 通常是在 C++ 或 Java 中完成超快的超优化代码，例如 XERCES，而大多数 JSON 解析器都属于您自己的或解释的类别。
在快速网络环境（LAN 或宽带）中，发送 1 或 2 K 与 10 至 15 k 之间没有太大区别。
【讨论】：
性能是一个广泛的话题。
如果您指的是服务器的负载，那么 REST 具有更好的性能，因为它在 HTTP 之上承担的开销最小。通常 SOAP 会带来一堆不同的（生成的）处理程序和解析器。无论如何，性能差异本身并没有那么大，但是 RESTful 服务更容易扩展，因为您没有任何服务器端会话。
如果您指的是网络性能（即带宽），REST 的性能要好得多。基本上，它只是 HTTP。没有开销。因此，如果您的服务无论如何都在 HTTP 之上运行，那么您不会比 REST 更精简。此外，如果您使用 JSON（而不是 XML）对表示进行编码，您将节省更多字节。
简而言之，我会说“是”，使用 REST 会提高性能。此外，它（在我看来）将使您的界面更容易为您的客户使用。因此，不仅您的服务器变得更精简，而且客户端也变得更精简。
但是，有几件事情需要考虑（因为你问'你会失去什么？'）：
RESTful 接口往往更“健谈”，因此根据您的域和您设计资源的方式，您最终可能会执行更多 HTTP 请求。
SOAP 具有非常广泛的工具支持。例如，顾问喜欢它，因为他们可以使用工具来定义接口并生成 wsdl 文件，而开发人员喜欢它，因为他们可以使用另一组工具从该 wsdl 文件生成所有网络代码。此外，作为表示的 XML 具有模式和验证器，这在某些情况下可能是一个关键问题。 （JSON 和 REST 确实有类似的东西，但工具支持远远落后）
【讨论】：
只是为了给 wuher 的回答补充一点。
使用 Chrome 网络浏览器请求此页面时的 Http Header 字节数：761
wikipedia 文章中的示例肥皂消息所需的字节数：299
我的结论：不是线路上的字节大小允许 REST 表现良好。
简单地将 SOAP 服务转换为 REST 不太可能获得任何显着的性能优势。 REST 的优势在于，如果您遵循约束，那么您可以利用 HTTP 提供的机制来生成可扩展系统。缓存和分区是您工具带中的工具。
【讨论】：
您将问题表述为 REST 和 SOAP 在现有系统中以某种方式可以互换。他们不是。
当您使用 SOAP（一种技术）时，您通常拥有一个在“方法”中定义的系统，因为实际上您是在处理 RPC。
当您使用 REST（一种架构风格，而不是技术）时，您正在创建一个根据“资源”而不是方法定义的系统。 SOAP 和 REST 之间没有 1:1 的映射。系统架构根本不同。
或者您只是在谈论经常与 REST 混淆的“通过 URI 进行 RPC”？
【讨论】：
这一切都取决于。对于请求数据可能变大的情况，REST 并没有真正的（好的）答案。如果在大肆宣传 REST 时有时会忽略这一点，我会感到这一点。
让我们想象一个服务，它允许您请求数千个不同项目的信息数据。
SOAP 开发人员将定义一种方法，该方法允许您在一次调用中检索一个或任意多个项目的信息……。
REST 开发人员会担心他的 URI 会变得太长，因此他会定义一个将单个项目作为参数的 GET 方法。然后，您必须多次调用它，每个项目一次，才能获取您的数据。干净且易于理解......但是。
在这种情况下，REST 服务需要更多的往返行程才能完成对 SOAP 服务的一次调用即可完成的任务。
是的，我知道在 REST 场景中如何处理大型请求数据有一些变通方法。例如，您可以将内容打包到请求的正文中。但是您必须仔细定义（在服务器端和客户端）如何解释它。在这些情况下，您开始感到痛苦，因为 REST 并不是真正的标准（如 SOAP），而更像是一种做事方式。
对于只交换相对有限的数据量的情况，REST 是一个非常好的选择。归根结底，这是大多数用例。
【讨论】：
其他答案似乎忽略的一件事是 REST 对缓存的支持和 HTTP 的其他好处。虽然 SOAP 使用 HTTP，但它没有利用 HTTP 的支持基础结构。 SOAP 1.1 绑定只定义了 POST 动词的使用。这在 1.2 版中通过引入 GET 绑定得到了修复，但是如果使用旧版本或不使用适当的绑定，这可能是一个问题。
安全性是另一个关键的性能问题。 REST 应用程序通常使用 TLS 或其他会话层安全机制。 TLS 比使用应用程序级别的安全机制（如 WS 安全性）要快得多（WS 安全性也受到security flaws 的影响）。
但是，在比较基于 SOAP 和 REST 的服务时，我认为这些大多是次要问题。您可以找到解决 SOAP 或 REST 性能问题的方法。我个人的观点是 SOAP 和 REST（我所说的 REST 是指基于 HTTP 的 REST 服务）都不适合需要高吞吐量和低延迟的服务。对于这些类型的服务，您可能希望使用 Apache Thrift、0MQ 或无数其他二进制 RPC 协议。
【讨论】：
一般来说，基于 REST 的 Web 服务因其简单性、性能、可扩展性和对多种数据格式的支持而受到青睐。 SOAP 在服务需要对安全性和事务可靠性提供全面支持的情况下受到青睐。
答案实际上取决于功能性和非功能性需求。提出下列问题将帮助您做出选择。
参考：http://java-success.blogspot.ca/2012/02/java-web-services-interview-questions.html
服务是否公开数据或业务逻辑？ （REST 是公开数据的更好选择，SOAP WS 可能是逻辑的更好选择）。 消费者和服务提供者是否需要正式合同？ （SOAP 通过 WSDL 有一个正式的合同） 我们需要支持多种数据格式吗？ 我们需要进行 AJAX 调用吗？ （REST 可以使用 XMLHttpRequest） 调用是同步的还是异步的？ 调用是有状态的还是无状态的？ （REST 适用于无状态 CRUD 操作） 需要什么级别的安全性？ （SOAP WS 对安全性有更好的支持） 需要什么级别的事务支持？ （SOAP WS对事务管理有更好的支持） 我们的带宽有限吗？ （SOAP 更冗长） 对于将为服务构建客户端的开发人员来说，什么是最好的？ （REST 更容易实现、测试和维护）
【讨论】：
您不必做出选择，现代框架允许您以最小的更改以这些格式公开数据。遵循您的业务需求并对具体实现进行负载测试以了解吞吐量，如果没有对特定系统进行正确的负载测试，这个问题就没有正确的答案。
【讨论】：