我已经阅读了一些在这里发布的关于Soap和Rest的问题，并没有找到我正在寻找的答案。 我们有一个使用Soap网页服务构建的系统。 该系统性能不是很好，正在讨论是否将所有Soap网络服务替换为REST网络服务。 有人认为Rest具有更好的性能。 我不知道这是否正确（这是我的第一个问题）。 假设这是正确的，使用REST代替SOAP是否有任何劣势？（我们失去了什么吗？）
提前致谢。
REST和SOAP。REST的性能更好吗？
31
- Luixv
2
这是 https://dev59.com/FHVD5IYBdhLWcg3wDXF3 的副本吗？ - pjz
1你失去的是SOAP中的“过度工程”方面。加密、消息签名、身份验证、不可否认性、自描述服务等等。如果你需要做任何这些事情（大多数服务都不需要！），那么就选择SOAP。 - James Anderson
9个回答
48
性能是一个广泛的话题。
如果您指的是服务器负载，则REST有更好的性能，因为它在HTTP之上承载了最小的开销。通常，SOAP会带来一堆不同（生成的）处理程序和解析器。无论如何，性能差异本身并不大，但RESTful服务更容易扩展，因为您没有任何服务器端会话。
如果您指的是网络性能（即带宽），REST的性能要好得多。基本上就是HTTP。没有额外开销。因此，如果您的服务已经在HTTP之上运行，那么REST基本上是最简洁的了。此外，如果您使用JSON编码表示（而不是XML），则可以节省更多字节。
总之，我想说“是的”，使用REST您将更具性能。此外，它（在我看来）还将使您的接口更易于客户端消费。因此，不仅您的服务器变得更轻盈，客户端也会变得更轻便。
然而，需要考虑一些事情（因为您问“您会失去什么？”）：
RESTful接口往往会更加“喋喋不休”，因此取决于您的领域以及如何设计资源，您可能会进行更多的HTTP请求。
SOAP具有非常广泛的工具支持。例如，顾问喜欢它，因为他们可以使用工具定义接口并生成wsdl文件，而开发人员喜欢它，因为他们可以使用另一组工具从该wsdl文件生成所有的网络代码。此外，XML作为表示具有模式和验证器，在某些情况下可能是关键问题。（JSON和REST也有类似的东西，但工具支持远远落后）
- wuher
3
6除了REST接口更喜欢交流这一点我并不太信服，但除此之外这是一个扎实的回答。 - Darrel Miller
要真正回答这个问题，您需要针对特定的用例和特定的库实现进行处理。这个答案做出了太多的假设，从会话、"喋喋不休"到"更容易为客户服务"。 - serg.nechaev
RESTful服务可以拥有服务器端会话。通常通过cookie或自定义HTTP头实现。 - Oooogi
14
SOAP需要解析XML消息，并发送和接收所有那些<riduculouslylongnamespace:mylongtagname>极长的标签名extra</riduculouslylongnamespace:mylongtagname>之类的东西。
相比之下，REST通常使用更简洁易解析的JSON。
然而，在实践中，这种差异并不是很大。
从XML构建DOM通常使用像C++或Java中的XERCES这样的超快超优化的代码，而大多数JSON解析器属于自行编写或解释类型。
在快速网络环境（局域网或宽带）中，发送1或2K与10到15K之间的数据没有太大区别。
- James Anderson
2
Json 比 XML 慢。 - MariuszS
1它可能会更慢，也可能会更快，但最终它们都是以文本格式表示的数据。 - serg.nechaev
12
你将问题表述得好像REST和SOAP在现有系统中可以互换使用，但它们实际上是不能互换的。
当你使用SOAP（一种技术）时，通常会有一个基于“方法”定义的系统，因为实际上你正在处理RPC。
当你使用REST（一种架构风格，不是技术）时，你正在创建一个基于“资源”而非“方法”定义的系统。SOAP和REST之间没有一对一的映射关系，系统架构本质上是不同的。
或者你只是在谈论“通过URI进行RPC”，这经常被误认为是REST吗？
当你使用SOAP（一种技术）时，通常会有一个基于“方法”定义的系统，因为实际上你正在处理RPC。
当你使用REST（一种架构风格，不是技术）时，你正在创建一个基于“资源”而非“方法”定义的系统。SOAP和REST之间没有一对一的映射关系，系统架构本质上是不同的。
或者你只是在谈论“通过URI进行RPC”，这经常被误认为是REST吗？
- jbrendel
2
6如果您的应用程序设计具有松耦合性，则 Web 服务实现将是可互换的。您的答案有点离题，并且您对一个您一无所知的系统可互换性的假设是错误的。 - BentOnCoding
3我认为这是一个合理的回答。虽然它以寻求澄清的问题结束，但如果它在很大程度上试图用相关的事实信息回答问题，那么这并不会使它无效作为一个回答。虽然它没有直接涉及性能问题，但它涉及到了问题的基本前提的有效性，这对于提供完整的回答是相关的。(是否正确或错误是另一回事，最好通过赞成/反对票而非删除投票来解决。) - Adi Inbar
5
我对SOAP和REST的区别并不是很了解，但我知道它们之间唯一的性能差异在于SOAP在发送/接收数据包时有很多开销，因为它基于XML，需要SOAP头等。REST使用URL +查询字符串来发送请求，因此在网络传输中发送的数据量较少。
我相信这里的其他人可以给你更好、更详细的答案，但至少我已经尽力了 ;)
我相信这里的其他人可以给你更好、更详细的答案，但至少我已经尽力了 ;)
- KBoek
5
其他答案似乎忽略了REST支持缓存和HTTP的其他好处。虽然SOAP使用HTTP，但它没有利用HTTP的支持基础设施。 SOAP 1.1绑定仅定义了POST动词的使用。随着GET绑定的引入，版本1.2已经修复了这个问题，但如果使用旧版本或不使用适当的绑定，则可能会出现问题。
安全性是另一个关键的性能问题。 REST应用程序通常使用TLS或其他会话层安全机制。与使用WS Security等应用程序级安全机制相比，TLS要快得多（WS Security也存在安全漏洞）。
然而，我认为这些在比较基于SOAP和REST的服务时基本上都是小问题。您可以找到解决SOAP或REST性能问题的方法。我的个人观点是，对于需要高吞吐量和低延迟的服务，SOAP和REST（我指基于HTTP的REST服务）都不合适。对于这些类型的服务，您可能希望选择像Apache Thrift、0MQ或其他众多二进制RPC协议之类的东西。
安全性是另一个关键的性能问题。 REST应用程序通常使用TLS或其他会话层安全机制。与使用WS Security等应用程序级安全机制相比，TLS要快得多（WS Security也存在安全漏洞）。
然而，我认为这些在比较基于SOAP和REST的服务时基本上都是小问题。您可以找到解决SOAP或REST性能问题的方法。我的个人观点是，对于需要高吞吐量和低延迟的服务，SOAP和REST（我指基于HTTP的REST服务）都不合适。对于这些类型的服务，您可能希望选择像Apache Thrift、0MQ或其他众多二进制RPC协议之类的东西。
- Shawn H
4
一切取决于具体情况。REST并没有（好的）解决方案来处理请求数据可能变得非常大的情况。我认为在炒作REST时有时会忽略这一点。
我们可以想象一个服务，允许您请求成千上万个不同项目的信息数据。
SOAP开发人员将定义一个方法，允许您在单个调用中检索一个或多个项目的信息。
REST开发人员则会担心他的URI会变得过长，因此他会定义一个GET方法，该方法将以单个项目为参数。然后，您需要多次调用此方法，每次为一个项目，才能获取您的数据。干净而易于理解...但是。
在这种情况下，为了完成SOAP服务的单个调用所能实现的内容，REST服务需要进行更多的往返操作。
是的，我知道在REST场景下有如何处理大型请求数据的解决办法。例如，您可以将数据打包到请求的正文中。但是，您必须仔细定义（在服务器和客户端两侧）如何解释这些数据。在这些情况下，您会开始感受到REST并不是真正的标准（像SOAP一样），而是一种做事的方式。
对于只交换相对较少的数据量的情况，REST是一个非常好的选择。归根结底，这是大多数使用情况。
我们可以想象一个服务，允许您请求成千上万个不同项目的信息数据。
SOAP开发人员将定义一个方法，允许您在单个调用中检索一个或多个项目的信息。
REST开发人员则会担心他的URI会变得过长，因此他会定义一个GET方法，该方法将以单个项目为参数。然后，您需要多次调用此方法，每次为一个项目，才能获取您的数据。干净而易于理解...但是。
在这种情况下，为了完成SOAP服务的单个调用所能实现的内容，REST服务需要进行更多的往返操作。
是的，我知道在REST场景下有如何处理大型请求数据的解决办法。例如，您可以将数据打包到请求的正文中。但是，您必须仔细定义（在服务器和客户端两侧）如何解释这些数据。在这些情况下，您会开始感受到REST并不是真正的标准（像SOAP一样），而是一种做事的方式。
对于只交换相对较少的数据量的情况，REST是一个非常好的选择。归根结底，这是大多数使用情况。
- peterh
2
这是一个与服务设计有关的问题，与REST架构模式无关。我看到SOAP服务同样会很啰嗦。你可以设计漂亮的基于REST的服务，而不必诉诸于冗长、复杂的URL结构。 - Shawn H
1我想我试图表达的观点是，当请求很大且具有复杂的数据结构时，我不认为REST非常优雅。这些情况确实存在，但必须承认，在大多数情况下，请求中的数据很小且琐碎，并且在这种情况下（我相信这是所有情况的大多数），与SOAP相比，REST是一个绝佳的选择。在REST世界中，如果请求很大，那么您必须将请求数据嵌入到主体中，以避免URL变得过长。然后呢？这对于互操作性有好处吗？ - peterh
4
只是想补充一下wuher的回答。
在使用Chrome浏览器请求此页面时，HTTP头字节数为761。
维基百科文章中示例SOAP消息所需的字节数为299。
我的结论：REST表现良好并不是因为在传输过程中的字节大小。
简单地将SOAP服务转换为REST不太可能带来任何显著的性能优势。 REST的优势在于，如果遵循约束，则可以利用HTTP提供的机制来生成可扩展的系统。 缓存和分区是您工具箱中的工具。
- Darrel Miller
6
我把我的昵称从jedi改成了wuher（这个回答是指Jedi的回答，所以现在实际上是Wuher的回答）。对于造成的困惑，我感到很抱歉，我一开始就不应该选择Jedi这个昵称。 - wuher
1我认为这不是一个公平的比较，开发一个与维基百科上的SOAP示例相同的基于REST的示例，在网络传输方面会比维基百科的示例更小。 - stevenrcfox
@Overflow REST系统要求进行无状态、自描述请求，这会导致信息在网络上传输时存在冗余。SOAP系统可以保持会话状态，以避免重新发送某些信息的需要。基于消息大小选择REST而不是SOAP是不明智的。 - Darrel Miller
@Darrell Miller 如果你要强调问题，仅仅依靠消息大小可能是不明智的，但也不要拿苹果和橙子进行比较。 - stevenrcfox
@Overflow 我认为比较HTTP头与SOAP正文更为恰当，而不是尝试比较SOAP和REST。原始问题本质上存在缺陷。我只是试图提供一些实际的观点。 - Darrel Miller
@DarrelMiller 如果您在相同的数据上进行比较并执行相同的操作，则HTTP标头与SOAP正文之间的比较可能是有效的。我不会争论您答案的观点，只是认为使用不恰当的比较/类比来表达一个好观点会降低该观点的价值。 - stevenrcfox
1
一般而言，由于其简单性、高效性、可扩展性和对多种数据格式的支持，REST基础的Web服务更受欢迎。当服务需要全面支持安全性和事务可靠性时，SOAP更受青睐。
答案实际上取决于功能和非功能要求。询问下面列出的问题将有助于您做出选择。
参考：http://java-success.blogspot.ca/2012/02/java-web-services-interview-questions.html
答案实际上取决于功能和非功能要求。询问下面列出的问题将有助于您做出选择。
参考：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更易于实现、测试和维护）
- Sampath Kumar Madala
0
您无需做出选择，现代框架允许您以最小的更改将数据暴露在这些格式中。根据您的业务要求进行负载测试特定实现，以了解吞吐量，没有正确的答案，除非对特定系统进行正确的负载测试。
- serg.nechaev
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接