我读了一些关于肥皂和休息的帖子 我找不到我要找的答案。 我们有一个使用Soap Web服务构建的系统。 该系统性能不高，正在讨论中 替换所有用于REST Web服务的Soap Web服务。 有人认为Rest有更好的表现。 我不知道这是不是真的。 （这是我的第一个问题） 假设这是真的，使用是否有任何不利之处 REST而不是Soap？ （我们失去了什么吗？）
提前致谢。
答案 0 :(得分：46)
表现是一个广泛的主题。
如果您的意思是服务器的负载，那么REST的性能会更好一些，因为它在HTTP之上的开销很小。通常，SOAP会带来一堆不同的（生成的）处理程序和解析器。无论如何，性能差异本身并不大，但RESTful服务更容易扩展，因为你没有任何服务器端会话。
如果您的意思是网络性能（即带宽），则REST具有更好的性能。基本上，它只是HTTP。没有开销。因此，如果您的服务无论如何都运行在HTTP之上，那么您就不会比REST更精简。此外，如果您使用JSON（而不是XML）对表示进行编码，则可以节省更多字节。
简而言之，我会说'是'，你会更好地使用REST。此外，它（在我看来）将使您的界面更容易为您的客户消费。因此，不仅您的服务器变得更瘦，而且客户端也变得更精简。
然而，有几件事要考虑（因为你问'你会失去什么？'）：
RESTful接口往往更“健谈”，因此根据您的域以及您如何设计资源，您最终可能会执行更多HTTP请求。
SOAP具有非常广泛的工具支持。例如，顾问喜欢它，因为他们可以使用工具来定义界面并生成wsdl文件，开发人员喜欢它，因为他们可以使用另一组工具从该wsdl文件生成所有网络代码。此外，XML作为表示具有模式和验证器，在某些情况下可能是关键问题。 （JSON和REST确实有类似的东西，但工具支持远远落后）
答案 1 :(得分：14)
SOAP要求解析XML消息，并且所有＆lt; riduculouslylongnamespace：mylongtagname＆gt; extra＆lt; / riduculouslylongnamespace：mylongtagname＆gt;要发送和接收的东西。
REST通常使用更简洁的东西，并像JSON一样轻松解析。
然而在实践中，差异并不是那么大。
从XML构建DOM通常是用C ++或Java中的XERCES这样的超快速超优化代码完成的，而大多数JSON解析器都是你自己或解释过的代码。
在快速网络环境（LAN或宽带）中，发送一个或两个K与10到15 k之间没有太大区别。
答案 2 :(得分：11)
您可以将问题说成是否在现有系统中REST和SOAP在某种程度上是可互换的。他们不是。
当您使用SOAP（一种技术）时，通常会有一个在'methods'中定义的系统，因为实际上您正在处理RPC。
当您使用REST（架构风格，而不是技术）时，您正在创建一个根据“资源”定义的系统，而不是根据方法定义的系统。 SOAP和REST之间没有1：1映射。系统架构根本不同。
或者你只是在谈论“RPC via URI”，它经常与REST混淆？
答案 3 :(得分：5)
对于SOAP与REST，我绝对不是专家，但我所知道的唯一性能差异是SOAP在发送/接收数据包时有很多开销，因为它基于XML，需要SOAP标头等等REST使用URL +查询字符串发出请求，因此不会通过网络发送那么多的KB。
我确信在这里还有其他人可以给你更好更详细的答案，但至少我试过了;）
答案 4 :(得分：5)
其他答案似乎忽略了一件事是REST支持缓存和HTTP的其他好处。虽然SOAP使用HTTP，但它不利用HTTP的支持基础结构。 SOAP 1.1绑定仅定义POST动词的使用。这是通过引入GET绑定在1.2版本中修复的，但是如果使用旧版本或不使用适当的绑定，这可能是一个问题。
安全性是另一个关键的性能问题。 REST应用程序通常使用TLS或其他会话层安全机制。 TLS比使用WS Security等应用程序级安全机制要快得多（WS Security也受到security flaws的影响）。
但是，我认为在比较基于SOAP和REST的服务时，这些主要是小问题。您可以找到SOAP或REST性能问题的解决方法。我个人认为，SOAP和REST（REST都不是指基于HTTP的REST服务）都不适合需要高吞吐量和低延迟的服务。对于这些类型的服务，您可能希望使用Apache Thrift，0MQ或无数其他二进制RPC协议。
答案 5 :(得分：4)
只是为wuher的回答添加一点。
使用Chrome网络浏览器请求此页面时的Http标头字节数：761
wikipedia文章中的示例肥皂消息所需的字节数：299
我的结论：线路上的字节大小不是允许REST运行良好的。
简单地将SOAP服务转换为REST将极有可能获得任何显着的性能优势。 REST的优点是，如果您遵循约束，那么您可以利用HTTP为生成可伸缩系统提供的机制。缓存和分区是工具带中的工具。
答案 6 :(得分：3)
一切都取决于。对于请求数据可能变大的情况，REST实际上没有（好的）答案。如果有人在招揽REST时有时会被忽视，我觉得这一点。
让我们设想一个服务，它允许您为数千个不同的项目请求信息数据。
SOAP开发人员将定义一种方法，允许您在一次调用中检索一个或多个项目的信息....
REST开发人员会担心他的URI会变得太长，因此他会定义一个GET方法，该方法将单个项目作为参数。然后，您必须多次调用此项，每次调用一次，以获取数据。干净，易于理解......但是。
在这种情况下，REST服务需要更多往返才能完成SOAP服务上单个调用所能完成的任务。
是的，我知道如何处理REST方案中的大型请求数据有变通方法。例如，您可以将内容打包到请求的正文中。但是，您必须仔细定义（在服务器端和客户端端）如何解释它。在这些情况下，您开始感受到REST不是真正的标准（如SOAP），而是更多的一种做事方式。
对于只交换相对有限数量的数据的情况，REST是一个非常好的选择。在一天结束时，这是大多数用例。
答案 7 :(得分：1)
通常，基于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更容易实现，测试和维护）
答案 8 :(得分：0)
您不必做出选择，现代框架允许您以最小的更改公开这些格式的数据。遵循您的业务要求并对特定实施进行负载测试以了解吞吐量，如果没有对特定系统进行正确的负载测试，则无法正确回答此问题。