快手、孩子王、华为等专家分享大模型在电商运营、母婴消费、翻译等行业场景的实际应用 了解详情
写点什么

Bill Burke 谈 REST-*、SOA/ROA 和 REST

  • 2009-10-11
  • 本文字数:3582 字

    阅读完需:约 12 分钟

InfoQ 最近对REST-*.org 进行了报道,文章涉及REST-* 的公告以及部分社区反应,引起了许多反响。最终,部分反馈也让REST-*.org做出了些改变。Infoq 有幸采访了REST-* 项目的带头人 Bill Burke ,以进一步了解详情。

InfoQ: 您能介绍一些自己的情况么?

我目前就职于 Red Hat 的 JBoss 部门。我曾经从事过集群、EJB 容器、AOP 实现和应用服务器内核的开发。我目前正在领导 RESTEasy 项目,同时也在推进 REST-*.org。最后,我还出版过一些书籍,今年 11 月会由 O’Reilly 出版一本关于 JAX-RS 的书。

InfoQ: 是什么让您拥抱了 REST?

我拥抱 REST,将其作为一种实现分布式系统的可行之路花了一段时间。当我向 JBoss 中的其他人以及 Java 社区宣传 REST 的时候,我常常看到了同样的爬坡斗争。一开始,我认为 REST 是一种以非常简单、轻量级的方式去实现平台之间和语言之间真正互操作性的方法。随着我对其了解越多,我开始意识到,除了互操作性,REST 的架构原则可以让应用开发者极大地解耦服务和应用之间的互操作。

InfoQ: 您能对最后一点详细阐述一下么?在您看来,REST 如何提供了更好的解耦?

我认为关键的原则是:RESTful 系统是媒体类型和它们之间的超链接驱动的。客户端可以请求它们知道如何与之交互的数据结构。返回的数据包含客户端和服务器交互所需知道的全部信息(超链接)。当系统的新特性在线出现时,新的媒体类型可以提供额外的链接。

我正想以此来构造我们在 REST-*.org 要创建的规范。在我们定义中间件服务接口时,总有大量的边界情况常常使得 API 变得臃肿。我期望 REST-* 的核心规范去关注核心资源和链接关系的定义。基本上,我想针对每个 REST-* 正在为之创建规范的领域去定义一个指定新媒体类型的框架和指导方针。这将让社区有大量机会去试验不同的数据格式,进而将帮助我们对核心模型进行微调。

InfoQ: 您在 JBoss World 大会期间进行了一次非常优秀的演讲,试图对比 SOA 和 ROA。您能对此作进一步的阐述吗?

当我在 1 月份完成我这个 JBoss World 大会幻灯片的第一版草稿的时候(我已经在不同会议上使用了这个幻灯片的几个迭代版本了),我碰到了一个由Anne Thomas Manes 在InfoQ 发布的关于SOA 治理的优秀幻灯片。她在其中谈论了在组织中部署SOA 时约束的重要性。要是没有约束,管理、集成和重用服务的复杂度就会随组织中越来越多的应用上线而呈指数上升。REST 谈论的内容正是定义分布式接口的约束。既然它是如此强大的解耦工具,那么在大型组织中推广它绝对是件非常有意义的事情。如果你将其和HTTP 协议的普遍性结合起来,你也就可以在这个混合环境中加入真正轻量级的互操作性。

InfoQ: 在你的很多幻灯片和帖子里,你都强调了 HTTP 协议对于 REST 的作用。你是否认为不可靠、无连接的 HTTP 是发生服务通信的主要媒介?

正如 Roy 一再强调的那样,REST 并不仅限于 HTTP。那就是说,在目前这个时候,还没有其他普遍存在的应用协议可以替代 HTTP 来实现真正轻量级的跨平台互操作性。在新的事物出现之前,HTTP 将不得不继续发挥主要作用。正如 REST 的布道者们说的那样,Web 本身已经做得相当不错了。

InfoQ: 你已经好几次说过,REST 的主要优势是它要比 WS 实现轻得多的事实。另一方面,随着我们提高抽象级别,使用如 JAX-RS,它的量级大大变重了。例如 RESTEasy 就包含了 38 个 jars。您认为这种趋势会继续吗,REST 堆栈的大小会赶上 WS 堆栈的大小吗?

在 RESTful 环境中进行 HTTP 调用要比在 WS-* 中轻得多。主要原因在于,除了发送请求所需的 HTTP,WS-* 还需要一个信封格式。换句话讲,WS-* 在 HTTP 之上还构建了其他协议。除了定义所有你的媒体类型,还需要使用 WSDL 定义这种 WS-* 协议。在 REST 中,你只需要定义你的媒体类型。操作和消息格式都是预先定义好的。

尽管 REST 堆栈可能会变大并赶上 WS 堆栈的大小,但从应用的观点或堆栈提供者的观点看,它并不需要变得太复杂而难以实现。REST 的解耦和动态天性结合 HTTP 的内容协商可以提供一种方法既使基本交互和媒体类型保持简单,同时为更复杂的协议提供了钩子,以了解新媒体和链接关系创建过程中发生的事情。

但是,对 RESTEasy 得要公平些,其核心真的只有些其他 Java 项目也可能有的依赖:一个 Servlet 容器、日志 API 和一个 HTTP 客户端库。其他的 jar 处理 RESTEasy 与其他组件模型(如 Spring、Guice 和 EJB)的集成,以及通过使用第三方流行的库(如 Jettison、Jackson、James、Abdera 和 JAXB)来支持象 JSON、XML、Multipart、Atom 和 XOP 这样的数据格式。使用 Servlet 容器,你绝对没有理由不能开发 RESTful 服务,但是我保证你会用到我们打包的许多第三方库。

不管怎么说,我们已经在 Maven 上作了大量工作,因此你可以挑选你想要包含的依赖。

InfoQ: 很多人都认为服务互操作性的基础是预先制定契约和早期验证。您认为 REST 对此的答案是什么?WADL?

不,我认为我们不需要一个和 WSDL 一样的东西。在 REST 中,互操作性是由客户端和服务器之间交换的媒体类型和链接关系定义的。换句话讲,这种交换的媒体类型就是契约。

InfoQ: 很多人都认为 REST 的一个主要优点是限制了方法的数量,这意味着所要求的动作往往必须被“编码”到服务的有效负荷之内。你认为 4 是一个最佳的方法数吗?

首先,在 REST 中,动作永远都不应该被编码到一个有效负荷之内。客户端应该将动作建模为状态。

但是,我想你更可能是在讲 REST 的统一接口约束吧?SQL 只有 4 个方法就可以建模相当复杂的交互和应用。但要回答你的问题:“PUT、POST、GET 和 DELETE 是否就够了?”我认为对于大多数系统来说它们就够了。我还认为有可能需要“OPTIONS”,它可以用于服务描述。当你有客户端只想通过链接将资源彼此链接时,“LINK”和“UNLINK”可能会有些有趣的用例。

InfoQ: 那么 REST-* 背后的目标是什么?

我们的目标是找出象工作流引擎、业务流程管理、消息解决方案,甚至是事务管理器这样的传统中间件服务在 RESTful 架构和应用中适合的位置。我们将通过定义一系列规范和指导方针来完成这项工作,这些规范和方针定义了这些服务的接口。有一件事我们不会做,那就是定义 REST 的含义或通用的 RESTful 指导方针。这最好留给 REST 社区的聪明人去完成。我们将关注于企业中间件,因为那是我们的专业领域。

InfoQ: REST 社区中有些人认为,完成企业分布式计算所需的全部材料在 REST 和 HTTP 中都已经存在了。那我们为什么还需要 REST-*?

大多数对 REST 的描述都会伴随使用人类 Web(Human Web)来作为例子。对于“人类 Web”,我认为是浏览器和使用这些浏览器的人。在我看来,基于机器的客户端如何与一个 REST 架构交互,还远未成熟。企业 IT 过去习惯使用特定的中间件技术去实现它们的分布式应用。REST 的到来让我们有机会反思传统企业 IT 开发是如何与中间件交叉的。这正是 REST-*.org 试图解决的问题。我最终发现 REST 是中间件的死亡原因,但我猜想答案就位于其中的某个位置。

InfoQ: 您如何看待 REST-* 未来的发展?

我们首先会着手定义一系列我们想要为之创建 RESTful 接口的服务,以及每个这些服务将要解决的特定问题。从这一努力中,我们还希望得到一系列横跨我们正在特别定义的领域(如安全)的通用指导方针。当我们觉得我们获得的实质成果足以发表,我们将会把我们的工作带到象 IETF 或 W3C 这样的标准团体。

InfoQ: 参与的流程是怎样的?比方说,它对个人是开放的吗?还是仅仅只针对厂商?

REST-*.org 是一系列的开源项目,其目标是定义规范和指导方针。我们发布的所有东西都将是开源许可的。我们目前已经选择了 ASL 2.0,但也有可能将该许可证变更到其他许可证。

既然我们将 REST-*.org 作为开源项目运营,我们要做的每一件事也将是以开放方式完成。任何个人和组织都可以参与。他们要做的全部事情就是订阅我们的邮件列表。我们还希望外部公司或个人能推动部分我们的规范努力。尽管 Red Hat 是这个努力的发起者,但我们认为我们并不适合就是这些努力的主要推动者。

InfoQ: REST 和 REST-* 在 JBOSS 中的未来怎样?

我们已经发现,随着我们的产品沿时间演变,使用传统的方法去定义我们的分布式管理和工具接口会变得太脆弱和难于管理。许多工程师都在寻找一种更好的方法。我认为 REST 可以解决部分这些问题。我们已经看到了一些将 REST 应用于我们某些产品的管理接口的好处。我希望它也将对配置和供应我们的项目和产品的方式有正面影响。

至于 REST-*,我们将在 RESTEasy 开源项目之下构建我们规范的初始实现。通过将我们的想法付诸实现,这将给我们提供一个有价值的反馈环。

InfoQ: 您最后还有什么话想说?

多年以来,分布式计算似乎是相同旧思想、模式和技术的不断重新打包。通过 REST,我最终感觉分布式计算的再次演变和发展。尽管 REST 无法解决世界饥荒,但它肯定将给我们带来实践软件工程的新观点。

查看英文原文: Bill Burke Discusses REST-*, SOA/ROA and REST

2009-10-11 06:591993
用户头像

发布了 255 篇内容, 共 56.5 次阅读, 收获喜欢 10 次。

关注

评论

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

高级java体系课第1期第二周作业

刘博

案例 | 在肯尼亚,青年们正在说着“Sheng”语...

澳鹏Appen

人工智能 nlp 数据标注 训练数据 小语种

明道云致几位重度抄袭者的公开信

明道云

软件测试 | 测试流程体系

测吧(北京)科技有限公司

测试

云原生技术在容器方面的应用

统信软件

容器 云原生 云服务

4道数学题,求出极狐GitLab CI 流水线之最优解|第1题:有向无环图流水线

极狐GitLab

ci DevOps cicd pipeline 极狐GitLab

“采访”ChatGPT看看它对我们GreatSQL社区有什么看法

GreatSQL

MySQL greatsql greatsql社区

关于小游戏引擎你还了解哪些?

没有用户名丶

小程序游戏

五大要点,让你掌握代码整洁之道!

SoFlu软件机器人

从 await-to-js 到 try-run-js

jump-jump

JavaScript 异步 优化 Async 重试

分布式缓存服务DCS:企业版性能更强,稳定性更高

华为云开发者联盟

云计算 后端 华为云 企业号 2 月 PK 榜 华为云开发者联盟

陕西旅游集团旗下景区春节期间累计接待超200万人次,这背后也有火山引擎VeDI的身影

字节跳动数据平台

大数据 数据中台 字节跳动 数据产品

直播预告 | 数据库自治平台 KAP 监控告警架构及实例演示

KaiwuDB

监控告警 KaiwuDB 数据库自治

渲染行业需要什么,云渲染的优势是什么?

Renderbus瑞云渲染农场

云渲染 云渲染农场 云渲染平台

软件测试 | 项目管理与跨部门沟通协作

测吧(北京)科技有限公司

测试

大规模敏捷测试怎么做?--基础篇

QE_LAB

敏捷测试

软件测试 | 常用测试管理平台

测吧(北京)科技有限公司

测试

Apifox 1 月更新 | 将接口调试做到「极简」的新模式上线

Apifox

Apifox API

设计模式-策略模式详解

C++后台开发

设计模式 策略模式 后端开发 Linux服务器开发 C++开发

软件测试 | 软件测试体系

测吧(北京)科技有限公司

测试

软件测试 | 流程管理平台

测吧(北京)科技有限公司

测试

如何通过Java应用程序将OpenDocument 演示文稿(.odp)转换为PDF

在下毛毛雨

Java PDF 转换格式 ODP文档

VSCode一键接入Notebook体验算法套件快速完成水表读数

华为云开发者联盟

人工智能 华为云 企业号 2 月 PK 榜 华为云开发者联盟

银斯微, W-Sharing取得TTA与PaaS-TA兼容级别1双项认证

科技热闻

区块链项目开发技术团队源码交付

开发微hkkf5566

2023年最新互联网大厂精选Java面试真题集锦(JVM、多线程、MQ、MyBatis、MySQL、Redis、微服务、分布式、ES、设计模式)

架构师之道

编程 程序员 计算机 java面试

什么是智能制造,为什么它对传统制造业影响如此之大?

PreMaint

智能工厂 智能制造

智商狂飙,问了ChatGPT几个数据库问题后,我的眼镜掉了

NineData

人工智能 MySQL 数据库 ChatGPT NineData

全景剖析阿里云容器网络数据链路(四):Terway IPVLAN+EBPF

阿里巴巴云原生

阿里云 容器 云原生

有了 ETL 数据神器 dbt,表数据秒变 NebulaGraph 中的图数据

NebulaGraph

数据库 大数据 数据处理 图数据库

Flink SQL 在米哈游的平台建设和应用实践

Apache Flink

大数据 flink 实时计算

Bill Burke谈REST-*、SOA/ROA和REST_SOA_Boris Lublinsky_InfoQ精选文章