SOAP与REST:务实的案例研究？

我对SOAP vs REST问题给出的答案不满意: SOAP与XML-RPC或REST的性能

因为这只是一般的哲学答案,而不是一些研究案例的实用答案.

没有人可以准确地说出肥皂何时比休息更合适的情况,特别是从性能的角度来看？

更新:我认为REST赢得了战争.

表现不是决定因素.

首先我应该说,问一个SOAP-vs-REST问题有点小问题,因为SOAP是一种XML信封格式,而REST是一种架构.所以我会做一点假设,并假设你真的在考虑SOAP-vs-POX或SOAP-vs-JSON或SOAP-vs- 其他一些数据格式化方法.

决定因素应该是:
您现在需要,或者将来需要SOAP信封吗？

SOAP Envelope允许使用框架提供的加密,digsig,路由和授权检查等功能.当然,您可以使用REST(或更准确地说,使用普通的XML或JSON等)来执行这些操作,但您必须自己做更多的工作才能实现.

如果性能 - 无论你的意思是什么 - 真的是你的第一标准,那么你应该放弃SOAP和POX并转向protobufs或其他针对性能优化的东西.这些可以更快地序列化并且更快地传输.

如果你认为这个答案是"过于哲学"而且你真的想要硬数字,那么我想你需要进行一些测试.您选择的工具包,消息的形状以及您使用的额外数据服务(如加密等)的实际性能差别很大.但最终,无论是哪种方式,性能都不会或不应该是决定性的.

如果您的SOAP工具包更容易使用20%.调试和维护作为您的POX工具包,然后您应该使用SOAP,无论性能如何.如今,人们(程序员,架构师,测试人员)比CPU和网络要昂贵得多.如果您的设计正确,您可以随时购买另外2个cpu或更大的网络.但是,如果您的框架难以使用,或者它驱走了您的员工,那么您不可能不惜一切代价购买20%的时间.除非您运行的是地理规模的网络,否则您最好为人员而不是网络进行优化.

你可以在这里找到一篇比较REST和SOAP的文章:http: //www.jopera.org/files/www2008-restws-pautasso-zimmermann-leymann.pdf

作者的结论似乎是:

使用RESTful服务进行Web上的战术,临时集成

在专业的企业应用程序集成场景中,优选WS-*Web服务,具有更长的使用寿命和更高的QoS要求

就个人而言,我不喜欢像"专业企业"这样的术语,因为它是松散和非正式的.但是在我看来,作者在文章中提出了一些好处.也许总结并给出一些自己的想法:

如果你想公开API - 以RESTful方式做.为什么？它很容易用于客户端应用程序,因此它将使您的服务更受欢迎.例如,亚马逊暴露了REST和SOAP API,但85%的用户选择了REST版本Amazon API - SOAP与REST

如果您要创建(或者您可以控制创建过程)服务的消费者和生产者,并且您确实需要WS-*的高级功能,请使用SOAP和WS-*堆栈.这可能还需要更多资源,因为SOAP应用程序往往"更重"(更多功能,但也更复杂).

同时考虑性能REST可能更快(消息肯定更短,您不需要解析xml).

希望它会有所帮助.

在你的flash客户端的例子中 - 在不知道细节的情况下很难分辨,但如果不需要WS-*的所有这些安全性和事务性功能,我认为构建REST应用程序会更简单,更快.

回答评论

我应该用肥皂,因为我在所谓的"专业企业"

当然,假设您的选择并非真正由大型软件供应商决定.

SOAP适用于大型企业,因为它鼓励采用更正式的方法.它提供了巨大的规范,因此您的开发人员可能需要时间来学习它们,甚至可能需要一些专业培训 - >所以花费公司资源.它还提供工具 - 并非所有工具都是开源的,因此这也意味着额外的资源.但是,如果您的团队将学习这种集成服务的方式,那么它可能会很有效并且生成的代码将具有高质量.

相反,REST更像是一种开发应用程序的哲学.所以,没有庞大的规格,没有专门的工具.没有资源支出.如果你有一个优秀程序员的小团队,这可能会很好 - 如果他们知道基本原则,他们就不需要这么多指导.不幸的是,做错事也更容易.

另一件需要考虑的事情是应用程序大小 - API越丰富,您想要集成的服务越多,RESTful就越难.建立小型SOAP应用程序也不是一个好主意 - 整个开销和入口成本太高.

您需要评估项目的利弊.如果不知道我认为的所有细节,就不可能提出建议.

最后 - 这与合理的论点无关,而与政治有关.我认为管理层人员似乎更喜欢WS-*堆栈和SOAP(它支持"大企业",因此他们更容易为自己的选择辩护).另一方面,来自学术背景[1]的人更喜欢REST - 因为在该领域仍有许多研究可以进行.

[1]我介于两者之间,所以我可以观察这两种行为;-)