为什么要使用 REST 而不是基于 SOAP 的服务？[关闭]

题

今天参加了一个关于 REST 的有趣演示，但是，我想不出任何一个理由（也没有提出）为什么 REST 无论如何都比基于 SOAP 的服务堆栈更好或更容易使用和实现。

“现实世界”中的任何人使用 REST 而不是基于 SOAP 的服务的原因有哪些？

解决方案

更少的开销（没有 SOAP 信封来包装每个调用）

减少重复（HTTP 已经代表了 DELETE、PUT、GET 等操作）否则必须在 SOAP 信封中表示）。

更加标准化 - HTTP 操作易于理解并且操作一致。一些 SOAP 实现可能会变得很挑剔。

更易于人类阅读和测试（仅使用浏览器测试 SOAP 更困难）。

不需要使用 XML（对于 SOAP，您也不需要使用 XML，但这几乎没有意义，因为您已经在解析信封了）。

图书馆让 SOAP（某种意义上）变得简单。但正如我所指出的，您正在抽象掉底层的大量冗余。是的，理论上 SOAP 可以通过其他传输，以避免在顶层执行类似的操作，但实际上，您所做的几乎所有 SOAP 工作都是通过 HTTP 进行的。

其他提示

宁静的服务的消费比肥皂基础（常规）服务。原因是 REST 基于普通的 HTTP 请求，可以从发出的请求类型（GET = 检索、POST = 写入、DELETE = 删除等）推断意图，并且完全无状态。另一方面，您可能会认为它不太灵活，因为它取消了包含请求上下文的消息信封的概念。

根据我的经验，企业内部的服务首选 SOAP，而作为公共 API 公开的服务首选 REST。

使用 .NET 框架中的 WCF 等工具，将服务实现为 REST 或 SOAP 非常简单。

一些相关阅读：

我假设当您说“Web 服务”时，您指的是 SOAP 和 WS-* 标准集。（否则，我可能会认为 REST 服务是 “网页服务”。）

典型的论点是，REST 服务更接近 Web 的设计，即 HTTP 和相关基础设施的设计。因此，使用 REST 服务将与现有的 Web 工具和技术更加兼容。

当然，一旦深入细节，你就会发现这两种方法在不同场景下各有优势。您对这些细节感兴趣吗？

开销并不像好的架构那么重要。

REST 不是一种协议，而是一种鼓励良好可扩展设计的架构。之所以经常选择它，是因为 RPC 中太多的自由度很容易导致糟糕的设计。

另一个原因是 HTTP 上的 RESTful 协议的成本是可预测的，因为它可以利用现有技术（主要是代理）。RPC 初始成本相当低，但随着负载的加剧，成本往往会显着增加。

REST 与实现无关并且更加透明，这使得它非常适合公共 API，特别是对于像 Flickr、Amazon 或 Digg 这样使用其 API 作为营销工具并真正希望人们使用其数据的大型网站。他们不希望帮助成千上万的新手开发人员尝试调试他们选择的脚本语言中存在缺陷的 SOAP 库。

与 SOAP 和 WSDL 相比，后者更适合内部应用程序，在内部应用程序中，两端都有嵌入式库和已知的线索人员。（而且您可能不必关心互联网规模的负载平衡、HTTP 缓存等事情。）然后您将获得自记录、保留类型等的 API。零工作。

必须阅读罗伊·菲尔丁最优秀的著作论文关于这个话题。他提出了一个很好的案例，并且绝对是方式当他写这本书时（2000 年），这比他的时代还早。

史蒂夫·维诺斯基的博客和他的最新的文章绝对值得细读。他是一位前 CORBA 大师，与 Michi Henning 一起写了可能是该主题最好的书， “使用 C++ 进行高级 CORBA® 编程”. 。然而，他已经看到了他的客户端/服务器方式的错误，并且现在发誓使用 REST。

REST 允许您的非变异操作（通常使用 GET 动词） 缓存的. 。即，由客户端缓存和/或由代理缓存。这可能是一个巨大的胜利！

REST 基本上只是一种实现 Web 服务的方法。它只是正确使用 HTTP 来查询您尝试访问的 Web 服务的一种方法。

它超级简单又纤薄。您可以通过 http 动词使用浏览器来完成此操作：得到。我还没有找到可以轻松手动执行通用 http POST 请求的浏览器

这是一个数据点：Amazon 提供 REST 和 SOAP 两种格式的 API，其中 85% 的使用量是 REST。

REST 更容易实现、更容易理解并且性能更高。

许可以下： CC-BY-SA 和归因