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

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