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

作者 Stefan Tilkov译者 宋玮 发布于 2007年6月14日 下午10时26分

社区

Ruby,

SOA,

Java

主题

Web框架

标签

Restlet,

REST,

JSR 311,

Ruby on Rails

最近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：谢谢你抽出时间接受我们的采访。

---

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

• 更早的 >