REST 在企业中获得成功了么？

根据 Programmable Web 的数据，73% 的 API 都是 RESTful 的，因此有些人过早地得出了这样的结论——REST 已经赢得了胜利。但 SOA 从业者 Steve Jones 却指出使用这些 API 的都是用于数据聚合的前端系统，大多数企业系统并没有使用，因此 REST 尚未成功进军企业。

Mashery 的前 CTO Clay Loveless 在 Glue Con 2011 上作了题为“Lessons from the Failure of SOAP”的演讲，与大家分享了来自于 Programmable Web （一个 API 资源索引器）的一些统计数据，数据表明 SOAP 在过去几年间已经有了长足的进步，但其份额还是要小于 REST，而 REST 则处于平稳发展当中：

针对这些数据，SOA 从业者及 Capgemini 数据管理部门的全球总监 Steve Jones 说到，他们并不能准确表示出现如今 REST/SOAP 的使用情况，因为 Programmable Web 并没有收集企业数据：

那么对于 Oracle、SAP、IBM 或微软的企业技术栈的调查结果是怎样的呢？我认为其基数相当大，并且有很多已经用在实际产品当中了，其基数为 2368 ，够多了吧？我曾经呆过的公司的 SOAP 端点数比这还要多。如果将 SAP、Oracle 以及 Oracle AIA Behemoth 的 WSDL 库也考虑进来，那么数量就更多了，Oracle 对此并没有过分宣扬，因为已经够复杂了。回到 2005 年，那时 Oracle 曾宣称他们的应用使用了 3000 个 Web Services。

对于 REST 与 SOAP 之间的论战，来自于 ReadWriteWeb 的编辑 Alex Williams 在 Glue Con 上报道说 SOAP 并没有死，而是“会继续存在一段时间”，因为 SOAP 扎根于企业，我们很难轻易地摆脱掉它。

Jones 对 Williams 的文章发表了评论，他说 SOAP 还会继续存活于企业，而 REST 则是刚刚破茧而出：

SOAP 并没有死，它依然在企业中得到了广泛的应用，事实上，在集成各个厂商（大量的企业 IT）的解决方案时，SOAP 依旧是唯一可靠的方式。 面向企业的 REST 则刚刚破茧而出，它至少还需要 5 年的时间才能发展起来。

此外，Jones 又发表了一篇文章，谈到过去一年中， REST 在企业集成与治理方面并没有取得多少进展，原因在于发布、版本化及测试上：

首先说明一点，我这里所说的 REST 指的是一种企业集成方法，而非为了内容聚合而实现的一种 Web API 的公开方式，它是一种面向企业的功能性集成方法。REST 要比“缺陷多多”的 WS-* 好多了。那么它今年的发展势头如何呢？有一些小公司涌入了企业栈，声称他们可以创建 REST 接口，但实际上大多数都做不到这一点，因为接口发布、版本化及测试等关键问题尚未得到解决。

InfoQ 有幸采访到了 Programmable Web 的创建者 Clay Loveless 与 John Musser 以期了解他们对 Jones 关于企业与 REST 文章的看法。

他们也认为 SOAP 还将在企业中存活一段时间，但 REST 终将取胜：

我认为 Steve Jones 说得很对，我之前也曾说过：SOAP 还将存在很长一段时间，特别是在企业中。 企业对变化的反应速度很慢，很大程度上都是由厂商——消费者之间的关系所驱动的。如果企业的中层管理人员不能把钱花在支持合同上，那么他们就会觉得自己的工作没做好。

企业在商业空间上总是落后一步，过去是，将来也是。在 B2C 世界中，REST 已经赢取了胜利，John 的 [Musser] 数字已经证明了这一点。当公司认识到他们无法在 SOA 职位上招聘到合适的人选时，他们就会使用 REST 进行快速且代价更低的构建，这时变化就产生了。这种情况一时半会还不会出现，但迟早会出现。与之类似，印刷机与黑莓都在走向没落，但这两个领域的人们却都在极力否认这一事实。

Musser 曾在 Glue Con 2011 上就 API 的现状发表过一次演讲，展示了与上图中相同的数据，他坚信趋势是不可避免的，REST 最终将会征服企业：

我同意 Steve 与 Clay 的观点，SOAP API 在企业中还将存在相当长的一段时间。主要的推动力可能是 REST 与 SOAP 的技术方向，无论是技术上的原因还是 CIO 拍脑袋想出来的，最终都是由职责所推进的。Steve 认为现在有大量应用和企业工具还在使用 SOAP 与 WS-* 技术。 我在上周演讲中所说的是如果回到 2005 年，那时 SOAP 在基于 Web 的 API 中风头很强劲，但再看看从那时起到现在的 6 年间，你会清楚地发现 REST 所占的市场份额越来越大。这里所要表述的并不是目前实现或端点的总数，而是发展趋势。看看面向企业的厂商在关注什么，你会发现是 REST。当然了，他们并不是要放弃 SOAP，看看 Salesforce.com 吧（在过去长达 10 年的时间内，他们一直在使用 SOAP，但现在却在使用 REST 或是微软的 Azure 平台）。

我们还采访了 Steve Jones 以深入了解他认为 REST 尚不适合于企业的原因。

InfoQ：你说过在过去一年当中，REST 在 EA 集成领域没有取得丝毫的进展，依据是什么呢？有具体的数字么？这个结论是否是根据你所在的企业而得出的呢？

SJ：我看到 REST 在企业中有了一点儿发展，但这一切都是在 Web 端而非企业系统间的内部集成。我的结论也是根据 Programmable Web 的数据得出的，其中一个例子就是 SAP 链接（ https://streamwork.com/developers ），这实际上是个 REST API，用于 REST 领域当中。前端集成与聚合。

Programmable Web 列出了不到 2500 个 API，其中来自于 SAP 的只有一个，Oracle 则一个都没有。这表明 REST 社区根本就没有意识到企业集成的现实及其面临的挑战。

InfoQ：你提到了 REST 在内容聚合上的发展，但却说 REST 在 EA 集成上并没有取得多少进步。能否谈谈这两个领域间的差别么？我们该如何做才能让 REST 适用于 EA？接口发布与版本化么？

SJ：数据与功能。如果我想在一个页面上查看 5 个不同系统中的所有账户时，那么 REST 就是最适合的方式（只要通过 MDM 方案能在每个系统中识别出客户的键就可以）。但如果我要打开 5 个账户、将其传递给计费系统，然后让团队能够独立处理他们（这是关键），那么 REST 就不适合了。

企业集成要处理的是将各个领域分离开来，然后通过定义良好的边界让其能够独立运作。这些边界常常是通过外包，或是通过厂商的分包实现的。REST 的本质要求这些边界是不固定的，如果将其固定起来就会出现问题，现实情况是固定的边界是一件好事，因为它能让团队独立工作。因此，发布功能性契约（WSDL）的能力就是 SOAP/WS-* 的核心优势，这些契约可以被多种技术栈所使用。

对于 REST 与 MDM 来说，它本身就能很好地说明边界。REST 需要从多个系统中聚合关于同一个消费者的信息。“真正的”REST 方式会有一个中央消费者系统，所有人都通过一个 URI 来使用它，这就是唯一的 ID。现实情况是 SAP 与 Oracle 等系统总会保留消费者信息的本地副本，因此我们需要使用某种形式的功能集成与信息同步。这正是 WS-* 的用武之地，因为它提供了一种方式来“创建用户”并且可以返回“同步消费者”。

从纯技术角度来看，关于 SOAP 与 REST 之间差别的讨论并没有意义（ http://service-architecture.blogspot.com/2006/05/soap-v-rest-more-pointless-than-vi-v.html 、 http://service-architecture.blogspot.com/2006/09/why-rest-v-ws-is-irrelevant-in-two.html ），现实情况是企业需要集成的是发布契约的能力，这种契约不仅要从技术角度能够使用，而且人类也应该知道如何调用它。WSDL 虽然有种种弊端，但在这一点上要比 REST 简单。

企业集成的现实是采取的方法（入 MDM）要比具体的技术在集成的复杂度与灵活性上有着更大的影响。

InfoQ：你认为 REST 的未来将会怎样？

SJ：现在天花乱坠的宣传太多了，很多人都在抱怨其他人并不“知晓 REST 的真谛”，但却忽略了 REST 的缺陷。我希望 REST 的拥趸们能够醒醒，并就描述 REST 的功能接口的标准方式上达成一致（ http://service-architecture.blogspot.com/2010/01/define-standards-first.html ），这是最基本的事情，但很多人却吵着说这违背了 REST 的原则。或许问题在于 REST 从根本上来说是关于数据遍历与聚合的，它并不适合于面向功能的方式。

InfoQ：如果不采取 REST，同时 SOAP 又因为其复杂性而饱受诟病，那么 EA 集成的未来会怎样呢？

SJ：企业集成非常复杂。它要比人们所能想象得到的 Web 集成还要复杂，因为他们需要高性能。速度并不等于性能。企业集成非常复杂，但却与 REST 和 SOAP 之间的技术差异没有多少关系，对于企业开发者来说，REST 更加复杂，因为它无法通过标准的方式来定义功能接口。

改进企业与 B2B 集成的方法是向这些接口添加更多的形式，这样就会减少文档各自为政的情况。举个例子，指定出生日期时要限定在某个日期之后，在打开账户前需要进行信用检查，这都会起到很大的帮助作用。

批评 B2B 与企业集成中 SOAP 过于复杂的人忽略了这样一个事实——复杂源于何处。复杂来自于你需要集成多个不同的业务领域，同时又缺少标准的核心业务以及技术方法（比如 MDM）。技术方法只不过用于在网络上传输 XML，而相对于旧有的方法来说，SOAP 已经大大简化了这一点，因此它实际上是降低了复杂性。REST 并没有做到这一点，因此并未得到使用。

Jones 又在 Twitter 上说到“mosesjones：我可能错了，REST 最终将会赢得企业市场，但 REST 拥趸们需要更加实际一些，而不是单单从技术角度看待问题”。

你有何经验？REST 适合你的企业么？你是否解决了 Jones 提到的那些问题了么？你觉得 REST 会在未来的企业市场中抢占 SOAP 的宝座么？

此文在 InfoQ 英文站发布以后引来众多读者的评论，现摘取其中几位读者的评论，也许他们的想法与您不谋而合。

读者 Steve Jones 说到：

我认为 Clay 所说的企业对变化的反应速度过慢是不正确的。SOAP/WS 从人们眼中的救世主到成为事实上的企业集成方式经历了 4 年时间。REST 的拥趸们喜欢假设企业的反应速度过慢、笨重、甚至有点儿蠢，但现实情况却是当一项技术可行，它的传播速度会非常快，这也能够说明为何 WS-RM、WS-Security 以及其他的 WS-* 只用了几年时间就普及了。企业的脚步很快，厂商的脚步也很快，这意味着工具、自动化、测试与安全产品的发展速度都是非常迅捷的。 相比之下，过去 5 年间，REST 领域只新增了很少几个 API，很多还是来自于企业级厂商，但没几个是标准，更不必说元类型了，REST 的工具与自动化更是一片空白。

或许 REST 会取得胜利，但在企业集成项目中，我的经验是 SOAP 仍将会完全统治 MQ Series 和其他基于消息的方案，REST 或许会成为继 ETL 之后的第 4 个解决方案。

读者 Faisal Waris 说到：

无契约风格的 REST 实际上根本就不存在，我们现在使用的是具有隐式契约的 Web API（但没有元数据来描述服务接口）。 服务端与服务端之间的交互通常都是基于 WS* 的，因为工具可以轻松处理基于 WSDL 的服务接口。浏览器与服务器之间的交互最终都是通过 HTTP 进行的。

后端使用 SOAP 实际上是有多种原因的。比如说，发布——订阅以及通过 ESB 一 XML 网关实现的异步消息、使用了 WS-Security 的 B2B 消息等。企业开发者似乎更喜欢使用 XML Schema（以灵活性作为代价）描述服务接口。

读者 Gerald Loeffler 说到：

这些观点与我在集成项目中的经历完全吻合——看到这些我感觉一下子放松了不少，我在想自己所经历的这一切是不是具有代表性。 然而，文中所述的“SOAP 与 REST 之间差别”的“纯技术视角”并不是“无意义的争论”：虽然现在看来这种争论有些过时，但如果不基于纯技术进行比较，那么我们就会失去任何技术领域都需要的严谨。当然了，除了“纯技术视角外”还有其他很多内容值得讨论，但我总觉得“架构风格”与“业务接口”这两个概念已经对此强调很多了。Jones 所倡导的是根据业界的使用情况来判断“成功”抑或“失败”，并且借此寻找“失败”的原因（比如缺少精确的接口定义语言，如 WSDL）。

此外，Jones 提到“人们抱怨其他人并不知晓 REST 的真谛”，这得出了这样一个事实：当人们以一种方式全神贯注地观察世界时（这叫做意识形态，比如 WS-* 与 REST，抑或静态类型与动态类型），他们不可避免地就会将其看作是真理。但事实并非如此：这只不过是观察世界的一种方式而已。但遗憾的是，在软件开发中，某些人所宣扬的真理通常要通过侮辱其对手来实现，就好比“并不知晓 REST 的真谛”这句。

读者 Dave Duggal 说到：

没有银弹。我们在基于一个图形模型进行开发，使用 RESTful 调用（HTTP 作为传输层）协议（本身是资源）以在运行期通过传进与传出的上下文来修剪图形。

查看英文原文： Is REST Successful in the Enterprise?