SOAP 与 REST：实用案例研究？答案

【问题标题】：SOAP vs. REST: Pragmatic case studies?SOAP 与 REST：实用案例研究？
【发布时间】：2011-02-14 15:45:43
【问题描述】：

我对 SOAP 与 REST 问题给出的答案不满意，尤其是这里： Performance of SOAP vs. XML-RPC or REST

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

没有人能给出确切的例子说明肥皂何时比休息更合适，尤其是从性能角度来看？

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

【问题讨论】：

标签： web-services

【解决方案1】：

性能不是决定因素。

首先我应该说，问一个 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% 的开发时间。除非您正在运行地理规模的网络，否则您会更好地为人优化，而不是为网络优化。

【讨论】：

我喜欢这个，我只想补充一点，所有地理规模的网络都是从小的开始的。如果您发现自己正在转向地理范围，那么您将拥有资源来雇用可以帮助专门处理网络流量的人员。我认为最好的路线是“不能减少 20% 的开发时间”
我不同意“人要贵得多”，或者至少这取决于您的企业环境和项目。如果它是一家在网站上拥有数百万用户的大公司，那就没什么大不了的。重要的是：性能真的会提高吗？如果是，让我们尝试实现它。至于部署，这是另一个故事，因为涉及到许多部门，但这不是价格问题 :) 顺便感谢您的回答。
我认为性能是决定因素只有当它有一个数量级的不同时，这里不是这种情况。我们说的是更多的开销或更少的开销，没有任何东西会以足够大的方式影响可伸缩性，从而保证以牺牲其他一切为代价痴迷于性能。
另外，根据我的经验，与正在完成的实际工作相比，Web 服务开销通常相形见绌。
使用大数据时，性能变得更加重要。然后使用 Apache Thrift 或 Proto-Buffers+gRPC 与使用 REST 或 SOAP 相比要好得多。

【解决方案2】：

您可以在此处找到比较 REST 和 SOAP 的文章： http://www.jopera.org/files/www2008-restws-pautasso-zimmermann-leymann.pdf

作者的结论似乎是：

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

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

如果您想公开 API - 以 RESTful 方式进行。为什么？它很容易用于客户端应用程序，因此它将使您的服务更受欢迎。例如，亚马逊公开了 REST 和 SOAP API，但 85% 的用户选择了 REST 版本Amazon API - SOAP vs. REST
如果您将创建（或者您对创建过程有一定的控制权）您的服务的消费者和生产者，并且您确实需要 WS-* 的高级特性，请使用 SOAP 和 WS-* 堆栈。这也可能需要更多资源，因为 SOAP 应用程序往往“更重”（更多功能，但也更复杂）。

还考虑到性能 REST 可能会更快（消息肯定更短，您不需要解析 xml）。

希望它会有所帮助。

在您的 Flash 客户端示例中 - 如果不了解细节，真的很难分辨，但是如果不需要 WS-* 的所有这些安全性和事务性功能，我认为构建 REST 应用程序会更简单、更快。

回复评论

我应该使用肥皂，因为我在里面称为“专业企业”

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

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

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

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

您需要评估项目的利弊。不知道我认为的所有细节是不可能给出推荐的。

最后——这与合理的论点无关，更多的是与政治有关。我认为管理层似乎更喜欢 WS-* 堆栈和 SOAP（它支持“大企业”，因此他们更容易证明自己的选择是合理的）。另一方面，具有学术背景[1] 的人更喜欢 REST - 因为该领域仍有大量研究可以进行。

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

【讨论】：

很好的答案，但要小心使用“客户”一词。如果您的意思是“JavaScript 客户端使用 XmlHttp 直接与服务对话”，那么您是对的，但如果您的客户端使用工具来生成与服务对话的 JavaScript 代理类，那么就不是那么回事了。
感谢您的想法。根据上面的文章，我应该使用肥皂，因为我在所谓的“专业企业”。但我知道，所谓的专业有时意味着“供应商目标企业”，其中技术选择更多地取决于商业利益，而不是纯粹的技术原因，这就是我问这个问题的原因:)