休息与肥皂。休息有更好的表现吗?

绩效是一个广泛的话题。

如果您指的是服务器的负载,那么REST的性能稍好一点,因为它在HTTP之上承担的开销最小。通常,SOAP会带来一堆不同的(生成的)处理程序和解析器。无论如何,性能差异本身并不大,但是RESTful服务更容易扩展,因为您没有任何服务器端会话。

如果您指的是网络的性能(即带宽),那么REST的性能要好得多。基本上,它只是HTTP。没有开销。所以,如果您的服务运行在HTTP之上,那么您就不能比其他服务更瘦。此外,如果您用JSON(而不是XML)编码您的表示,您将节省更多的字节。

简而言之,我会说“是的”,你休息的时候会表现得更好。而且,它(在我看来)将使您的界面更容易为您的客户消费。因此,不仅您的服务器变得更瘦,客户机也变得更瘦。

然而,有两件事需要考虑(因为你问“你会失去什么?”):

RESTful接口往往更“健谈”,因此,根据您的域以及如何设计资源,最终可能会执行更多的HTTP请求。

SOAP具有非常广泛的工具支持。例如,顾问喜欢它是因为他们可以使用工具来定义接口并生成WSDL文件,而开发人员喜欢它是因为他们可以使用另一组工具来从WSDL文件生成所有的网络代码。此外,XML表示具有模式和验证器,在某些情况下这可能是一个关键问题。(JSON和REST有类似的功能,但工具支持还远远落后)

SOAP要求解析一条XML消息,并且必须发送和接收所有<riduculouslylongnamespace:mylongtagname>额外的</riduculouslylongnamespace:mylongtagname>内容。

REST通常使用更简洁和易于解析的东西,比如JSON。

然而,在实践中,两者之间的差别并不大。

从XMLis构建DOM通常在C++或Java中实现了超快速优化的XECES代码,而大多数JSON解析器都是自己的或解释的。

在快速网络环境(LAN或宽带)中,发送一个或两个K与发送10到15 K之间没有太大差异。

您将这个问题表述为,在现有系统中,REST和SOAP是否可以互换。它们不是。

当您使用SOAP(一种技术)时,通常会有一个在“方法”中定义的系统,因为实际上您是在处理RPC。

当您使用REST(一种体系结构样式,而不是技术)时,您将创建一个系统,该系统是根据“资源”而不是方法定义的。SOAP和REST之间没有1:1映射。系统体系结构是根本不同的。

或者您只是在谈论“rpc-via-uri”,这常常与rest混淆?

对于SOAP和REST,我绝对不是专家,但我知道的唯一性能差异是SOAP在发送/接收数据包时有很多开销,因为它是基于XML的,需要SOAP头等。REST使用url+querystring发出请求,因此不会通过线发送那么多的kb。

我确信还有其他PPL在上面,所以谁能给你更好更详细的答案,但至少我试过了;)

其他答案似乎忽略了一件事,那就是REST对缓存的支持以及HTTP的其他好处。虽然SOAP使用HTTP,但它没有利用HTTP的支持基础结构。soap 1.1绑定只定义了post动词的用法。这在1.2版中得到了修正,引入了get绑定,但是如果使用旧版本或不使用适当的绑定,这可能是一个问题。

安全性是另一个关键性能问题。REST应用程序通常使用TLS或其他会话层安全机制。TLS比使用应用程序级安全机制(如WS-Security)快得多 security flaws )

但是,我认为在比较SOAP和基于REST的服务时,这些都是小问题。您可以找到解决SOAP或REST性能问题的方法。我个人的观点是,SOAP和REST(我的意思是基于HTTP的REST服务)都不适合于需要高吞吐量和低延迟的服务。对于这些类型的服务,您可能希望使用ApacheThrift、0MQ或无数其他二进制RPC协议。

只是在芜湖的回答中加一点。

使用Chrome Web浏览器请求此页时的HTTP头字节数:761
中的示例SOAP消息所需的字节数 wikipedia 文章:299

我的结论是:让REST运行良好的并不是线路上字节的大小。

简单地将SOAP服务转换为REST将不太可能获得任何显著的性能优势。REST的优势在于,如果您遵循这些约束,那么您可以利用HTTP为生成可伸缩系统提供的机制。缓存和分区是工具带中的工具。

这要看情况而定。对于请求数据可能变大的情况,REST实际上没有(好的)答案。我觉得这一点如果有时被忽视时,炒作休息。

让我们设想一个服务,它允许您请求数千个不同项目的信息数据。

SOAP开发人员将定义一个方法,允许您检索一个或任意多个项目的信息…一次通话。

REST开发人员会担心他的URI太长,因此他将定义一个get方法,该方法将以单个项作为参数。然后,为了获取数据,您必须对每个项目多次调用此函数,每次调用一次。干净易懂…但是。

在这种情况下,REST服务需要更多的往返行程来完成通过对SOAP服务的单个调用可以完成的工作。

是的,我知道在REST场景中,对于如何处理大型请求数据有解决方法。例如,您可以将东西打包到请求的主体中。但是,您必须(在服务器和客户机端)仔细定义如何解释这一点。在这种情况下,你开始感到痛苦,休息并不是一种标准(像肥皂),而是一种做事的方式。

对于交换的数据量相对有限的情况,休息是一个很好的选择。最后,这是大多数用例。

一般来说,基于REST的Web服务是首选的,因为它简单、性能、可扩展性和对多种数据格式的支持。在服务需要全面支持安全性和事务可靠性的情况下,SOAP是最受欢迎的。

答案实际上取决于功能和非功能需求。问下面列出的问题将有助于您的选择。

裁判: http://java-success.blogspot.ca/2012/02/java-web-services-interview-questions.html

服务是否公开数据或业务逻辑?(对于公开数据,REST是更好的选择,对于逻辑,SOAP WS可能是更好的选择)。 消费者和服务提供商是否需要正式合同?(SOAP通过WSDL有一个正式的合同) 我们需要支持多种数据格式吗?