我在这里读到了一些关于肥皂和休息的问题,但我找不到我要找的答案.我们有一个使用Soap Web服务构建的系统.该系统性能不高,正在讨论替换所有用于REST Web服务的Soap Web服务.有人认为Rest有更好的表现.我不知道这是不是真的.(这是我的第一个问题)假设这是真的,使用REST而不是Soap是否有任何缺点？(我们失去了什么吗？)
提前致谢.
表现是广泛的话题.
如果您的意思是服务器的负载,则REST具有更好的性能,因为它在HTTP之上承担最小的开销.通常,SOAP会带来一堆不同的(生成的)处理程序和解析器.无论如何,性能差异本身并不大,但RESTful服务更容易扩展,因为您没有任何服务器端会话.
如果您的意思是网络性能(即带宽),则REST具有更好的性能.基本上,它只是HTTP.没有开销.因此,如果您的服务无论如何都运行在HTTP之上,您就不会比REST更精简.此外,如果您使用JSON(而不是XML)对表示进行编码,则可以节省更多字节.
简而言之,我会说'是',你会更加高效地使用REST.此外,它(在我看来)将使您的界面更容易为您的客户消费.因此,不仅您的服务器变得更瘦,而且客户端也变得更精简.
但是,有几件事要考虑(因为你问'你会失去什么？'):
RESTful接口往往更加"健谈",因此根据您的域以及您如何设计资源,您最终可能会执行更多HTTP请求.
SOAP具有非常广泛的工具支持.例如,顾问喜欢它,因为他们可以使用工具来定义界面并生成wsdl文件,开发人员喜欢它,因为他们可以使用另一组工具从该wsdl文件生成所有网络代码.此外,XML作为表示具有模式和验证器,在某些情况下可能是关键问题.(JSON和REST确实有类似的东西,但工具支持远远落后)
SOAP需要解析XML消息以及所有
REST通常使用更简洁的东西,并像JSON一样轻松解析.
然而在实践中,差异并不是那么大.
从XML构建DOM通常是在C++或Java中使用超快速的超级优化代码片段,如XERCES,而大多数JSON解析器都是您自己的或解释的类别.
在快速网络环境(LAN或宽带)中,发送一个或两个K与10到15 k之间没有太大区别.
您可以将问题表达为REST和SOAP在现有系统中以某种方式互换.他们不是.
当您使用SOAP(一种技术)时,通常会有一个在"方法"中定义的系统,因为实际上您正在处理RPC.
当您使用REST(架构风格,而不是技术)时,您创建的系统是根据"资源"定义的,而不是根据方法定义的.SOAP和REST之间没有1:1映射.系统架构根本不同.
或者你只是在谈论"RPC via URI",它经常与REST混淆？
我绝对不是SOAP vs REST方面的专家，但是我知道的唯一性能差异是SOAP在发送/接收数据包时有很多开销，因为它基于XML，需要SOAP标头，等等。REST使用URL + querystring发出请求，因此不会通过网络发送那么多的kB。
我敢肯定，SO上还有其他人可以为您提供更好，更详细的答案，但是至少我尝试过；）
其他答案似乎忽略了一件事是REST支持缓存和HTTP的其他好处.虽然SOAP使用HTTP,但它不利用HTTP的支持基础结构.SOAP 1.1绑定仅定义POST动词的使用.这是通过引入GET绑定在1.2版本中修复的,但是如果使用旧版本或不使用适当的绑定,这可能是一个问题.
安全性是另一个关键性能问题.REST应用程序通常使用TLS或其他会话层安全机制.TLS比使用WS Security等应用程序级安全机制快得多(WS Security也存在安全漏洞).
但是,我认为在比较基于SOAP和REST的服务时,这些主要是小问题.您可以找到SOAP或REST性能问题的解决方法.我个人认为,SOAP和REST(REST都不是指基于HTTP的REST服务)都不适合需要高吞吐量和低延迟的服务.对于这些类型的服务,您可能希望使用Apache Thrift,0MQ或无数其他二进制RPC协议.
京公网安备 11010802040832号 | 京ICP备19059560号-6 