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

小开

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

Http://www.xfront.com/rest-web-services.html Http://en.wikipedia.org/wiki/representational_state_transfer

小开

我假设您说的“ Web 服务”是指 SOAP 和 WS-* 标准集。(否则，我可以认为 REST 服务是是“ Web 服务”。)

规范的论点是 REST 服务与 web 的设计更为匹配——也就是说，HTTP 和相关基础设施的设计。因此，使用 REST 服务将与现有的 Web 工具和技术更加兼容。

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

小开

最佳答案

更少的开销(没有包装每个调用的 SOAP 信封)

减少重复(HTTP 已经表示了诸如 DELETE、 PUT、 GET 等操作，否则这些操作必须在 SOAP 信封中表示)。

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

更具人类可读性和可测试性(仅用浏览器测试 SOAP 更困难)。

不需要使用 XML (对于 SOAP 也不需要使用 XML，但是由于您已经在解析信封，所以它几乎没有意义)。

库使 SOAP (某种程度上)变得简单。但是正如我注意到的，你正在抽象出下面的大量冗余。是的，理论上 SOAP 可以覆盖其他传输，以避免在一个层上做类似的事情，但实际上，几乎所有的 SOAP 工作都是通过 HTTP 完成的。

小开

RESTful 服务比基于 SOAP的(常规)服务更容易使用。这样做的原因是 REST 基于正常的 HTTP 请求，这使得可以根据请求的类型(GET = 撷取、 POST = write、 DELETE = DELETE 等等)推断出意图。.)完全没有国籍。另一方面，您可能会认为它不那么灵活，因为它摒弃了包含请求上下文的消息信封的概念。

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

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

相关阅读:

小开

读了 Roy Fielding 关于这个话题最优秀的论文。他提出了一个极好的情况下，绝对是方式超前他的时代，当他写的(2000年)。

小开

史蒂夫 · 维诺斯基的博客和他的最新文章绝对值得一读。他是前 CORBA 大师，他与 MichiHenning 合著的 “用 C + + 进行高级 CORBA 编程”可能是关于这个主题的最好的书。然而，他已经看到了他的客户机/服务器方式的错误，并且现在坚信 REST。

小开

这是超级简单和苗条。你可以通过浏览器的 http 动词: GET 做到这一点。我没有发现一个浏览器可以手动做一般的 http POST 请求很容易

小开

REST 与实现无关，而且更加透明，这使得它适用于公共 API，特别是对于像 Flickr、 Amazon 或 Digg 这样的大型网站，这些网站正在使用他们的 API 作为营销工具，并且真的希望人们使用他们的数据。他们希望能够掌握1000名新手开发人员，这些人正在尝试调试他们所选择的脚本语言中有缺陷的 SOAP 库。

相比之下，SOAP 和 WSDL 更适合于内部应用程序，在这两个应用程序的两端都有插件库和已知的聪明人。(你可能不需要关心互联网规模的负载平衡、 HTTP 缓存等等)然后你就可以得到自我文档化的 API，保存类型等等，而不需要做任何工作。

小开

REST 允许非变异操作(通常使用 GET 谓词)为缓存。也就是说，由客户端缓存和/或由代理缓存。这将是一场巨大的胜利！

小开

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

REST 不是一个协议，而是一个鼓励良好可伸缩设计的体系结构。之所以选择它，是因为 RPC 中过多的自由度很容易导致糟糕的设计。

另一个原因是基于 HTTP 的 RESTful 协议的可预测成本，因为它可以利用现有技术(主要是代理)。 RPC 的初始成本较低，但随着负荷的增加，RPC 的初始成本有明显增加的趋势。

小开

这里有一个数据点: Amazon 提供了 REST 和 SOAP 格式的 API，85% 的使用是 REST。

REST 更容易实现，更容易理解，性能更高。