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

  • Abel Avram
  • 张龙

2011 年 6 月 27 日

话题:SOAREST架构

根据 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.htmlhttp://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?

SOAREST架构