在十一月份,我们报道了Restfulie 项目的发布,该框架用于创建对超媒体敏感的客户端和服务。最近, Guilherme Silviera 将自己的 Restfulie 项目和 RESTeasy 进行了比较,后者是一个 JAX-RS 的实现,并质疑 RESTeasy(甚至于 JAX-RS)是否是构建 RESTful 应用的正确基础。这在社区里引起了一些讨论,因此,我们找机会采访了 Guilherme,借此来搞清楚事情的来龙去脉。
InfoQ:Guilherme 你好。你能先给我们介绍一下是什么原因让你决定开发 restfulie 的?
Guilherme: Jim Webber , Savas Parastatidis 和 Ian Robinson 将会在 2010 年初出版一本关于使用 web 作为基础结构的书, 我读了之后,终于明白了超媒体在 REST 场景中发挥作用的方式。回想到 Roy 和 Subbu Allamaraju 的一些作品和 JAX-RS 的实现,我们意识到过于强调了 Web 的 HTTP 和 URI 部分,而正如 Richardson 在 qcon 2008 上所指出的,我们对它的超媒体天性却重视不足。所以我们创建了 Restfulie,将其作为这样一种工具:首先关注超媒体方面,其次才是 HTTP 和 URI。
InfoQ:现在 Restfulie 社区有多大规模?
Guilherme:Restfulie 活跃的时间并不长,因此社区现在还比较小:但是它已经获得了我喜欢的正面评价。我们对于 Ruby 的贡献已经发布了并且正在向一些用户征集反馈。Jim Webber 在理论和现实问题上给予了我们帮助。 Jose Valim 和 Yehuda Katz ,都是 rails 3 的幕后工作者之一,也给了一些反馈让我们能够持续改进。在 ruby 社区享有盛名的 Brian Guthrie 和 Fabio Akita ,也贡献了代码和 DSL 的想法。
InfoQ:你对于标准怎么想,既然你的帖子是的的确确地在对比 restfulie 和 JAX-RS?
Guilherme:这是个很好的问题。想起成功发布的 JSR,我们总会想到 Hibernate/JPA。JCP 在 ORM 方面做的首次尝试 其实是 JDO,而 JDO 从来没有象 Hibernate 那样成功。原因有很多。在我看来,导致这发生的一个主要原因是自顶向下的工作方式,JDO 试图制定一 个新的 JSR,但缺少一个经过验证的解决方案 API 作为指导。当 Gavin King 帮助领导 JSR220 的时候,他们推出了 JPA1。JPA 2 进一步发掘了 Hibernate 被验证的功能,特别是 Criteria API。也就是必须要回答一个问题:开发者们会喜欢通过 String 来使用 Hibernate 风格的 Criteria,还是愿意使用新创建的 StaticMetaModel 方式来保证类型安全?
于是,我们已经看到了由委员会领导的标准技术和其他从成功 API 中提炼出想法引入到 JSR 的技术(如 Hibernate/JPA 和 Seam/CDI(原来 叫 WebBeans))的不同结局。标准的确很重要,但是现在是该我们从错误里学习的时候了。 在 JPA 和 CDI 的例子里,JBoss 在它现有经验之上成功的把 API 整合进了 JSR。 InfoQ 刚刚发表的 Rod Johnson 的演讲也强调了这一点:“Rod Johnson…介绍了从它的失败中学到的教训,就像委员会领导的标准…以后要避免再犯这样的错误”。
在收到帖子的反馈之后,对 Restfulie 的讨论,Jim Webber 是第一个在自己 blog 中发表看法的, “这不是RESTEasy (或Jersey, 或 CXF) 的错,有问题的是委员会驱动流程,在那里,怀着不同目的以及对REST 理解水平不同的人们在一起召开会议,得出了最低共性的结果,这就是JAX-RS”。 REST 领域必须被更谨慎地思考。JAX-RS 规范充分肯定了HTTP 和URI 的价值,但是对超媒体约束却很大程度上有所保留。每个其他的JAX-RS 实 现几乎都以自己期望的方式对超媒体相关的所有事情进行处理,并且正如规范所“强迫”的,他们的重点放在了对HTTP+URI 的支持上。就像Roy 指出 的,HTTP 是我们的API,所以也许一个直白的说法是,除了使用它,就不应该有其他标准api 的存在。
InfoQ:你考虑过参与 JAX-RS 项目中的一个而不是开发一个单独的 RESTful 框架吗?
Guilherme:Restfulie 产生于 Rails 环境,所以在构想阶段并没有真正考虑是这一点。由于在培训公司工作,我们深知对于学习者从一开始就接触最重要的思想是非常重要的,因为对 一个技术的第一印象将会影响使用它的方式。我们并没有按照文档遵循 JAR-RS(及其实现) 的标准路径:URI+HTTP,很久之后才是超媒体,最后是客 户端支持,这是因为我们期望我们能够让他们更好的思考超媒体的重要性以及 HTTP 和 URI。
首先关注超媒体,URI 和 HTTP 的需要会更自然地浮现:我们从客户得到的反馈是他们在用 REST 的超媒体方面,所以看起来客户们理解并且很好地利用了超媒体方法。Java 版以及它和 JAX-RS 标准的联系将会在接下来的问题中解决。
InfoQ:restfulie 的下一步要做什么?
Guilherme:我们刚刚发布了了一个 Java 版本(vraptor 和 hibernate),主要关注超媒体约束。当 vraptor3 出来的时候,我们不能确定它是否应该是一个 JAX-RS 的实现。标准很重要,给予市场新想 法的其他框架也同样重要。这也是我为什么认为 Restfulie 和 vraptor 适合当下。这将来也许会改变,如果我们发现真的有一个更好的方式来创建系 统:该 java 版本也会通过一些实现进一步强化,只要它没有放弃对超媒体的关注。
还有一些 Rails 2 版本重构,Rails 3 和.NET 的实现,对很多 http header 和 response 代码的客户端支持(Server 端已经支持了)。Restfulie 的客户端部分是最让我惊奇的,它有很多非常好的默认动 态绑定 URI 以及状态转换的相关特性,而不只是“http 之上的序列化工具”(也就是 jaxb 和 httpclient 等)。
InfoQ:感谢您花时间来回答我们的问题。
Guilherme:不用谢。
查看英文原文: http://www.infoq.com/news/2009/12/restfulie-interview 。
评论