写点什么

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

  • 2011-06-27
  • 本文字数:4909 字

    阅读完需:约 16 分钟

根据 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?

2011-06-27 01:133368
用户头像

发布了 88 篇内容, 共 254.4 次阅读, 收获喜欢 6 次。

关注

评论

发布
暂无评论
发现更多内容

☕【JVM技术之旅】彻底弄清楚Minor GC和Major GC及Full GC

洛神灬殇

JVM 垃圾回收 GC 5月日更

密码学基础

escray

学习 极客时间 安全 5月日更 安全攻防技能30讲

打击挖矿和交易行为!

CECBC

InnoDB 锁类型及其分析

luojiahu

innodb 死锁 间隙锁 意向锁

kube-controller-manager之PV Cotroller源码分析

良凯尔

Kubernetes 源码分析 Ceph CSI

低代码/无代码和简单API

YonBuilder低代码开发平台

低代码

感恩父母

若兮

520 单身福利

模块4-作业

yu

Flink的程序结构

大数据技术指南

flink 5月日更

聊聊一个普通程序员在520这天的心态

后台技术汇

520 单身福利

架构实战营 模块四作业

netspecial

架构实战营

加油!未来的每一天

Sherry

520单身福利 520 单身福利

Python数据科学基础-Pandas介绍

五分钟学大数据

数据科学 5月日更

梯度下降法 - DAY12

Qien Z.

5月日更 过拟合 梯度下降法

虽不能至,心向往之|靠谱点评

无量靠谱

加密货币终将替代黄金?总价值已接近私人持有黄金价值

CECBC

🚄【Redis 干货领域】帮你完全搞定Cluster原理(架构篇)

洛神灬殇

redis redis集群 5月日更 redis架构

Python自动化神器-Fabric

小圆子

520 单身福利

【音视频】基于声网实时音视频能力的音视频质量体系建设

轻口味

音视频 WebRTC 声网 质量指标

拿金钱考验人性|靠谱点评

无量靠谱

爱情从来都不是简单的事

阿泽🧸

520单身福利

C语言不完全类型是什么?有什么用途?

不脱发的程序猿

C语言 C语言不完全类型

WebContainers介绍:如何在浏览器运行原生的Nodejs

代码先生

大前端 webassembly 技术创新 WebContainers StackBlitz.com

网络攻防学习笔记 Day22

穿过生命散发芬芳

5月日更 网络攻防

Vue-2-常用指令

Python研究所

520 单身福利

模块四:课后作业

菲尼克斯

架构实战营

模块4作业4

dwade

#架构实战营

NLog整合Exceptionless

yi念之间

.net core exceptionless nlog

.Net Core Excel导入导出神器Npoi.Mapper

yi念之间

C# .net core npoi

ArrayList与LinkedList性能大PK

Damon

java基础 5月日更

缅怀袁老

topsion

随笔杂谈

  • 扫码加入 InfoQ 开发者交流群
REST在企业中获得成功了么?_SOA_Abel Avram_InfoQ精选文章