专访 Restlet 框架首席开发者 Jérome Louvel

阅读数:1602 2007 年 6 月 14 日

最近Restlet 框架发布了它的1.0 版。Jérome Louve 是 Java 框架 Restlet 的领导开发者,InfoQ 的编辑 Stefan Tikov 有机会和 Jérome Louvel 进行了一次对话,本次谈话的主题讨论了 Restlet 存在的原因、在 Java Web 服务框架中的 REST 支持、Ruby on Rails、对 JSR 311 的期望以及 Restlet 的路线图。

InfoQ:你能给我们简单地介绍下 Restlet 的目标吗?

Jérome Louvel(以下简称 JL):Restlet 是一个 Java 下的轻量级REST框架。通过拥抱 REST(REST 是一种 Web 架构风格)它模糊了 Web 站点和 Web 服务之间的界限,从而帮助开发人员构建 Web 应用。每一个主要的 REST 概念(REST concept)都有一个对应的 Java 类。你的 REST 化的 Web 设计和你的代码之间的映射是非常简单直接的。

Restlet 是一个以 CDDL 或 GPL 发布的开源项目。该项目包含一个 Restlet API,一个引用实现(Noelios Restlet 引擎)以及一套扩展。

InfoQ:你为什么会觉得有必要创建另一种框架?难道 Servlet API 还不够好用吗?

JL:Servlet AIP 在 1998 年发布,从那个时候起它的核心设计一直没有很大的变化。它是 Java EE 的众多 API 中最成功的一个,但是它的几个设计缺陷和一些限制损害了它。举个例子,URI 模式和它的处理者(handler)之间的映射是受限制的,而且其配置都集中在一个配置文件中。还有,他把 socket 流的控制直接交给了应用系统开发人员,Servlet 容器阻碍了我们充分使用 NIO 特性对 IO 操作进行优化。最后,他对一些 HTTP 特性,例如缓存、内容协商以及内容压缩支持的不好。这对开发人员来说是件痛苦的事,因为这阻碍了他们将精力集中在应用系统相关的代码上。

另一个主要问题是,Java EE Stack 中新的 HTTP 客户端 API 的缺少。JDK 的 HttpURLConnection 类很难用,而且许多 HTTP 特性都不支持,比如为内容协商而表达的客户端选择等。人们经常需要依赖第三方 HTTP 客户端 API 突破这些限制。但是,HttpURLConnection 不支持 NIO。

2005 年,我看到了超越这些限制的机会:在 REST 原则下设计一个新的 API。第一次,我们有了统一 Web 应用客户端和服务器端的机会,这个 API 完全支持 NIO 并能让开发人员编程控制 Web 容器、连接器(connector)等,而且不需要经常性的依赖 XML 描述符就能部署应用系统。

InfoQ:你怎么看在别的框架中对 REST 的支持(例如Axis2,或者CXF/XFire)?

JL:我想这些支持非常有效,但是作用非常有限。我的主要观点是设计这些项目是为了符合 WS-*/SOAP Stack,它们与 REST 世界并不非常契合。在 REST 世界里,定义了一个全新的范例:面向资源的设计,而非通过远程方法调用这样的范例。

例如 Axis2 仅仅支持 GET 和 POST 两种 HTTP 方法,它需要远程方法的传递需要一个 URI 参数。这在 REST 中式不允许的,这种做法也不能被称之为 REST 化。

XFire1.2 不支持 REST,但是它发布了一个项目用于将 POJO 映射到 REST 化的 Web 服务。这有点类似最近发布的JSR-311,此 JSR 试图基于一套 annotation 和助手类标准化这种映射。

InfoQ:你是JSR 311 专家组的成员,能否对 JSR 311 做一下展望?

JL:我期望它能在 REST 资源和 POJO 领域对象之间实现一个完好的映射。就像 JPA 在关系数据库和 POJO 之间实现了很好的映射那样,我们也希望这个 JSR 能做到像 JPA 那样。我希望以 annotation 为中心的 API 能够相当符合(complimentary)Restlet API,后者已经是一个将 REST 资源映射到 POJO 的以类为中心的 API 了。

这些 annotation 也能被像 Axis2 和 XFire 这样的项目实现,我认为这个 JSR 给了 REST 和 WS-* 阵营一个达成和解的机会。

InfoQ:你能告诉我们一些基于 Restlet 的项目吗?

JL:有几个不同规模的组织已经部署并应用了这样的应用系统,包括 Overstock.com,这是一个在线购物方面的 Internet 领导者。Restlet 项目也被作为支持技术用在覆盖 REST 构架风格的不同软件构架类别中。例如在加州 Irvine 大学,以及在 INSA Rouen 工程学院的使用。

我们自己的网站也是用 Restlet 引擎构建的。考虑到我们受到拒绝服务(denial of service)的攻击量,我们对我们系统的可伸缩性很自信。最近我们还发布了一个公用基准以证明了其性能品质。我们与流行的 Servlet 容器处在同一水平线上,而且有望在下一个加入完全的 NIO 优化的连接器(基于Glassfish 的 Grizzly NIO 框架)的版本中比后者表现更为优异。

InfoQ:在构建 REST 化的应用系统中,能否比较一下 Java 和其他语言有何不同?

JL:流行的 REST 化技术,例如 Rails 或者Django这些技术的经验告诉我们,Java/Restlet 这样的技术在支持 REST 化的应用中会有更好更高的性能表现。Rails 和 Django 开始的设计并没有考虑到 REST,REST 的这些概念只是在后来被加进去的。相比 Restlet,这导致了很多做作的(contrived)代码。以 Django 为例,它并不天然支持在 URI 和资源之间映射的 URI 模板。而 Rails 强迫在关系数据库和对数据的 CRUD 操作间使用一种不自然的映射,REST/HTTP 方法导致一种令人不满意的结果:开发人员不得不在各种限制下工作,或者采用自己的面向资源的设计去迎合 Rails。而 Restlet 不强迫你使用任何持久化技术,它让你自由的定义你的资源及其特定的表现形式(representation),以及它们怎么被映射到你的领域对象或你的数据库。

InfoQ:你能更详细的解释下你刚才对 Rails 的批评吗? 你认为它的 CRUD 映射什么地方不够自然?

JL:除了 GET 和 DETLET 这样的 HTTP 方法可以很好的映射到 SQL 的 SELECT 和 DELETE 外,我还发现 Rails 将 HTTP 的 POST 方法用来进行创建行为,这很不幸。在 REST 中,对于创建行为最好的方法是使用 PUT,它也可以用于更新。PUT 比 POST 优越的地方是如果操作行为失败了,它可以很安全的重复操作,而 POST 不行。

还有,资源列表是基于表名和行记录的数字型 id 映射的,在实践中这并不总是可行的。你不想失去对你的 URI 的控制,而 URI 既是应用系统用户界面的一部分,又是 REST 最基本的概念之一。在 Restlet 中,我们并不对你的 URI 强加任何限制,你可以自由的使用任一持久化技术(例如 JPA 的 annotation 化 POJO,纯 JDBC 调用,对象数据库等等)在你的资源和表现形式(representation)之间进行映射。

我对 Rails 的另一个小小的批评是,Rails 鼓励使用笨拙的“;edit”后缀访问一个资源的编辑 Web 页面。这有点误导,REST 并不鼓励使用 URI 参数的非一致方法,应该使用分隔的 Web 表单资源,这样浏览器可以使用 GET、POST 或者 PUT 方法。

InfoQ:你好像在 Restlet 上花了不少时间。这个业余项目占用了你多少时间,你的公司期望能从这个项目中得到多大的商业成就?

JL:从开始这个项目就不是作为一个业余产品启动的。当我构建另一个很重要的私人项目是我就感觉到了对它的需要。我相信专业的开源项目,也希望 Noelios Consulting 能提供的专业服务(如支持计划,顾问服务)能让我们继续投入更多的精力。

InfoQ:第一版发布之后的路线图是什么?

JL:除了维护 1.0 版修改 bug 外,我们还将很快启动 1.1 版。一些我们曾想过的对 WAR 包(不再需要 XML 描述符)的增强将被加进来。用户可以选择通过一个 XML 描述符配置 Restlet 组件(可移植的应用系统和虚拟主机容器)从而简化管理员的工作。我们还有几个连接器原型要实现,一个是基于 Grizzly NIO 框架的 HTTP 服务器连接器,它将带来更多的可伸缩性和响应(responsiveness)。另外两个 HTTP 连接器是基于 JXTA 的虚拟 socket(一个客户机和一个服务器)。

我们还想更深入的支持 HTTP 特性,例如内容范围(content range),Digest 和 WSSE 授权。我们还计划在 2008 年将 Restlet API 提交给 JCP。这有利于逐渐替代 Servlet API。

InfoQ:谢谢你抽出时间接受我们的采访。


作者简介:

Jérome Louvel 是一位软件架构师,它是

Noelios Consulting 公司

的创始人。在软件版本(Software edition)和咨询方面有超过 8 年的工作经验,它常年工作在欧洲和北美洲。他对 Java、REST、语义网以及商业过程集成有浓厚的兴趣。

译者简介:宋玮,有多年软件开发经验,从 2002 年开始就使用 Java,在各个项目开发过程中先后使用过 Struts、Oracle ADF、AspectJ 等。最近正在使用 Spring 及 Ruby on Rails,对敏捷方法有比较大的兴趣并做过一些尝试。他的 blog 为http://www.donews.net/victorsong。参与 InfoQ 中文站内容建设,请邮件至china-editorial@infoq.com

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论