Restfulie作者Guilherme Silveira专访

在十一月份，我们报道了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。