我已经阅读了一些在这里发布的关于Soap和Rest的问题,并没有找到我正在寻找的答案。 我们有一个使用Soap网页服务构建的系统。 该系统性能不是很好,正在讨论是否将所有Soap网络服务替换为REST网络服务。 有人认为Rest具有更好的性能。 我不知道这是否正确(这是我的第一个问题)。 假设这是正确的,使用REST代替SOAP是否有任何劣势?(我们失去了什么吗?)
提前致谢。
我已经阅读了一些在这里发布的关于Soap和Rest的问题,并没有找到我正在寻找的答案。 我们有一个使用Soap网页服务构建的系统。 该系统性能不是很好,正在讨论是否将所有Soap网络服务替换为REST网络服务。 有人认为Rest具有更好的性能。 我不知道这是否正确(这是我的第一个问题)。 假设这是正确的,使用REST代替SOAP是否有任何劣势?(我们失去了什么吗?)
提前致谢。
性能是一个广泛的话题。
如果您指的是服务器负载,则REST有更好的性能,因为它在HTTP之上承载了最小的开销。通常,SOAP会带来一堆不同(生成的)处理程序和解析器。无论如何,性能差异本身并不大,但RESTful服务更容易扩展,因为您没有任何服务器端会话。
如果您指的是网络性能(即带宽),REST的性能要好得多。基本上就是HTTP。没有额外开销。因此,如果您的服务已经在HTTP之上运行,那么REST基本上是最简洁的了。此外,如果您使用JSON编码表示(而不是XML),则可以节省更多字节。
总之,我想说“是的”,使用REST您将更具性能。此外,它(在我看来)还将使您的接口更易于客户端消费。因此,不仅您的服务器变得更轻盈,客户端也会变得更轻便。
然而,需要考虑一些事情(因为您问“您会失去什么?”):
RESTful接口往往会更加“喋喋不休”,因此取决于您的领域以及如何设计资源,您可能会进行更多的HTTP请求。
SOAP具有非常广泛的工具支持。例如,顾问喜欢它,因为他们可以使用工具定义接口并生成wsdl文件,而开发人员喜欢它,因为他们可以使用另一组工具从该wsdl文件生成所有的网络代码。此外,XML作为表示具有模式和验证器,在某些情况下可能是关键问题。(JSON和REST也有类似的东西,但工具支持远远落后)
SOAP需要解析XML消息,并发送和接收所有那些<riduculouslylongnamespace:mylongtagname>极长的标签名extra</riduculouslylongnamespace:mylongtagname>之类的东西。
相比之下,REST通常使用更简洁易解析的JSON。
然而,在实践中,这种差异并不是很大。
从XML构建DOM通常使用像C++或Java中的XERCES这样的超快超优化的代码,而大多数JSON解析器属于自行编写或解释类型。
在快速网络环境(局域网或宽带)中,发送1或2K与10到15K之间的数据没有太大区别。
只是想补充一下wuher的回答。
在使用Chrome浏览器请求此页面时,HTTP头字节数为761。
维基百科文章中示例SOAP消息所需的字节数为299。
我的结论:REST表现良好并不是因为在传输过程中的字节大小。
简单地将SOAP服务转换为REST不太可能带来任何显著的性能优势。 REST的优势在于,如果遵循约束,则可以利用HTTP提供的机制来生成可扩展的系统。 缓存和分区是您工具箱中的工具。
这项服务是否暴露数据或业务逻辑?(REST更适合暴露数据,SOAP WS可能更适合逻辑)。 消费者和服务提供者是否需要正式的合同?(SOAP通过WSDL有正式的合同) 我们需要支持多种数据格式吗? 我们需要进行AJAX调用吗?(REST可以使用XMLHttpRequest) 调用是同步还是异步的? 调用是有状态还是无状态的?(REST适用于无状态的CRUD操作) 需要哪种级别的安全性?(SOAP WS对安全性的支持更好) 需要哪种级别的事务支持?(SOAP WS对事务管理的支持更好) 我们的带宽是否有限?(SOAP更冗长) 对于将构建服务客户端的开发人员来说,什么最好?(REST更易于实现、测试和维护)
您无需做出选择,现代框架允许您以最小的更改将数据暴露在这些格式中。根据您的业务要求进行负载测试特定实现,以了解吞吐量,没有正确的答案,除非对特定系统进行正确的负载测试。