SOAP与REST:实用案例研究？

Question

我对SOAP和REST问题给出的答案不太满意，特别是这里：Performance of SOAP vs. XML-RPC or REST

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

没有人能给出soap在什么情况下比rest更合适的确切案例，特别是从性能的角度来看？

更新:我认为REST正在赢得这场战争。

Answer 1

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

作者的结论似乎是：

• 使用RESTful服务通过Web进行战术性临时集成
• 在具有更长生命周期和高级QoS要求的专业企业应用程序集成方案中首选WS-* Web服务

就我个人而言，我不喜欢“专业企业”这样的术语，因为它是松散和非正式的。然而，在我看来，作者在这篇文章中提出了一些好的观点。也许可以总结一下，并给出一些自己的想法：

• 如果你想让API公开化，可以通过RESTful的方式来实现。为什么？它很容易用于客户端应用程序，因此它将使您的服务更受欢迎。例如，亚马逊同时公开了REST和SOAP，但是如果您要创建(或者您可以控制创建过程)服务的消费者和生产者，并且您确实需要WS-*的高级功能，则85%的用户已经选择了REST版本Amazon API - SOAP vs. REST
• Use SOAP和WS-*堆栈。这可能还需要更多的资源，因为SOAP应用程序往往更“繁重”(功能更多，但也更复杂)。

此外，考虑到性能，REST可能会更快(消息肯定更短，不需要解析xml)。

希望这能有所帮助。

在你的flash客户端的例子中-如果不知道细节就很难判断，但是如果一个人不需要WS-*的所有这些安全和事务功能，我认为构建REST应用程序会更简单和更快。

回复评论

我应该使用soap，因为我是所谓的“专业企业”

当然，假设您的选择并不是由大型软件供应商决定的。

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

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

另一件要考虑的事情是应用程序的大小--应用程序接口越丰富，你想集成的服务越多，就越难实现RESTful。此外，构建小型SOAP应用程序可能不是一个好主意-整个开销和入门成本太高了。

你需要评估你的项目的利弊。我认为在不了解所有细节的情况下给出推荐是不可能的。

最后，这与合理的争论无关，更多的是与政治有关。我认为管理层似乎更喜欢WS-*堆栈和SOAP (它支持“大企业”，因此他们更容易证明自己的选择是合理的)。另一方面，来自学术background1的人更喜欢休息-因为仍然有很多研究可以在该领域进行。

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

Answer 2

性能不是决定因素。

首先，我应该说，问一个SOAP-vs-REST问题有点古怪，因为SOAP是一种XML信封格式，而REST是一种体系结构。因此，我将做一个小小的假设，假设您实际上正在考虑SOAP-vs-POX或SOAP-vs-JSON或SOAP-vs-某种其他数据格式化方法。

决定因素应该是这样的：

您现在需要还是将来需要SOAP信封？

SOAP信封允许框架提供的加密、数字签名、路由和授权检查等功能。当然，您可以使用REST (或者更准确地说，使用plain-old-XML或JSON等)来完成这些工作，但是您必须自己做更多的工作才能实现。

如果性能真的是您的第一标准，那么您可能应该放弃SOAP和POX，转而使用protobufs或其他针对性能进行优化的工具。这些可以更快地序列化和传输。

如果你认为这个答案“太哲学了”，而且你真的想要严格的数字，那么我想你需要进行一些测试。根据您选择的工具包、消息的形状以及您使用的额外数据服务(如加密等)，实际性能会有很大的不同。但最终，perf不会或不应该是决定性的。

如果您的SOAP工具包更容易使用20%。作为POX工具包进行调试和维护，那么您应该使用SOAP，而不管其性能如何。如今，人员(程序员、架构师、测试人员)比CPU和网络贵得多。如果有必要，如果您的设计是正确的，您可以随时再购买2个cpus或更大的网络。但是，如果你的框架很难使用，或者如果它赶走了你的员工，你就不能不惜一切代价减少20%的开发时间。除非您运行的是地理范围的网络，否则您将更好地为人民优化，而不是为网络优化。