REST 的业务用例

Justin Cormack 的一篇博文引发了关于 RESTful 架构在企业里的采用或缺失的热烈讨论。

…或多或少总会听见 CTO 说：“把它做成 SOAP 的 API，谁有什么支持或反对的意见吗？”就像在婚礼上出现的那种场景一样，没有人作声。但我坚决反对。SOAP 不会是一个良好架构的主干，然而现在我们还没有说不的能力。

在他解释了资源在企业里所扮演的角色之后，他拿出这一数据 20 位开发者中有 9 位更愿意于使用 REST 因为它生产性更高。他暗示使用基于 REST 的 API 所带来的简洁性压倒了从服务契约或者服务模式 (wsdl,xsd) 所生成的代理，这些代理可以构建于 WS-* 标准之上，也可能基于其它标准。

这并非牵涉到生成一大堆无用代码的程序。它牵涉到的是超文本 (HATEOS)，而不是映射数据库模型的晦涩文档。

接着他解释了企业里的资源这一概念，并以如何在 CRM 系统里对一个典型的客户进行建模作为例子进行了说明。

企业里的资源是什么？从客户开始。一个 CRM 系统很明显就是需要被建模的资源。你需要 API，通过调用它，来找出客户购买的产品，支持票据，你构建一个客户服务门户所必须的所有核心数据，以及内部的支持系统。

根据这一篇讲述 ROE(Resource oriented enterprise) 的文章所说，每个企业都有数据筒仓 (silo)；比如满足不同业务功能的筒仓，工资系统，人事系统等等。而把这些筒仓所表示的数据当作是可访问的资源来考虑，是有其好处的。这些好处表现在成本方面，同时也表现在你打开了这些数据的孤岛，然后可以用它们来驱动以作出有根据的业务决策。

…ROE 所要求的，就是它们必须更加开放它们本身。并不仅仅主要在技术方面，同时也要提供一种更好的对它们信息内容的抽象。在一个面向资源的企业里面，这明显是通过将它们集成到一个基于 URI 的访问模式来实现的。

根据 Justin 的说法，要做到这一点不难。

构建这一框架可以是循序渐进的。你要么需要已经提供了 REST API 的工具，这会让事情更简易，要么需要一个 web 应用开发框架。这是应用架构与 web 内容管理的一个交汇点。

除了他在他的博文里提到的企业迈向 ROE 的好处以外，他同时还汇集了一些来自 REST邮件列表的回应。

[它] 使得事物是人可浏览的，而声明使用它们是机器可浏览的 […] 业务逻辑变成了内容而不是数据，这里存在的再不是业务逻辑要像黑箱一样填充的参数表格，而是它们的状态变成了可发现，可访问，并且可推理的资源。

把 REST 引入企业 […] 帮助企业利用了 web 架构的灵活性，并且使得构建新的企业应用更加便宜和方便。

REST 的应用将 web 分散化的方面带入了企业的世界，并且支持一个网络的系统里的设计者和开发者可以创建并发展他们的组件，而不需要承担把他们聚到一个房间里来讨论 API 所消耗的资源与时间成本。[ Jan Algermissen 在 rest-discuss 邮件列表里写到。]

我相信 REST 对于超媒体的运用 […] 使得维护，部署与版本控制更加的容易，这一点在一个应用的维护阶段就转化成了业务上更低的成本。[ Darrel Miller 在 rest-discuss 邮件列表里谈到]。

同时，[…] 互操作性通过 REST 可以更容易的达到，这是由于 HTTP 的普遍性。同时这对于集成来说也有着极大的正面的副作用。我发自肺腑觉得 SOA 治理也能够真正的从 RESTful 架构的好处中得到收获，但我现在并没有什么细节的东西。[ Bill Burke 在 rest-discuss 邮件列表写到]。

Justin 着重强调了 Benjamin Carlyle 的观察，那就是你可以将 REST 视为 SOA 的一个演化，可以更好并且更容易的消费服务。我们正在见证企业里焦点从面向服务转移到对 RESTful 方案的采用吗？或者说像 Benjamin 所指出的那样，这是一种自然的演化？

查看英文原文： Business Case For REST