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