杰罗姆鲍威尔 是犹太人吗
InfoQ的Stefan Tilkov有机会与Java Restlet框架的首席开发人员JéromeLouvel进行了交谈，该框架刚刚发布了其1.0版本 。 涵盖的主题包括Restlet存在的原因，Java Web服务框架和Ruby on Rails中的REST支持，对JSR 311的期望以及Restlet的路线图。
InfoQ：您能简要介绍一下Restlet的用途吗？
JéromeLouvel（JL）： Restlet是用于Java的轻量级REST框架。 它通过拥抱REST（Web的体系结构样式）来帮助您构建模糊网站和Web服务之间界限的Web应用程序。 由于每个主要的REST概念都有对应的Java类，因此RESTful Web设计和代码之间的思维导图很简单。
它是一个开放源代码项目，使用CDDL许可证或GPL许可证（带有Classpath例外）分发。 该项目由Restlet API，参考实现（Noelios Restlet Engine）和一组扩展组成。
InfoQ：为什么您觉得有必要创建另一个框架-Servlet API不够好吗？
JL： Servlet API于1998年发布，自那时以来，其核心设计并未发生太大变化。 它是最成功的Java EE API之一，但存在一些设计缺陷和局限性。 例如，URI模式和处理程序之间的映射受到限制并集中在一个配置文件中。 而且，它直接将套接字流的控制权提供给应用程序开发人员，从而防止Servlet容器对IO进行一些优化，例如NIO功能的全部使用。 最终，它不能很好地支持HTTP功能，例如缓存，内容协商和内容压缩，这给开发人员带来了太多痛苦，并阻止他们专注于特定于应用程序的代码。
另一个主要问题是Java EE堆栈中缺少现代的HTTP客户端API。 JDK的HttpURLConnection类很难使用，并且留下了许多不支持的HTTP功能，例如表达客户端对内容协商的首选项。
通常，人们依靠第三方HTTP客户端API来解决这些限制。 同样，HttpURLConnection不支持NIO。
在2005年，我看到了一个超越所有这些限制的机会，并根据REST原理设计了一个新的API。 我们第一次有了一个统一客户端和服务器端Web应用程序的API，一个完全支持NIO的API和一个使开发人员能够以编程方式控制其容器，连接器和已部署的应用程序而不必始终依赖XML的API。描述符。
InfoQ：您如何看待其他框架（例如Axis2或CXF / XFire ）中的REST支持？
JL：我认为这种支持很有用，但范围非常有限。 我遇到的主要问题是，这些项目被设计为WS-* / SOAP堆栈，并且不适合REST世界，后者定义了一个全新的范例：面向资源的设计，而不是远程方法调用。
例如，Axis2仅支持GET和POST方法，并要求将远程方法作为URI参数传递。 REST中显然不允许这样做，甚至不应将其标记为RESTful。
XFire 1.2不支持REST，但已公开了一个将POJO映射到RESTful Web服务的项目。 这将类似于最近的JSR-311所追求的方法，该方法旨在基于一组注释和帮助程序类来标准化此类映射。
InfoQ：您是JSR 311专家组的成员 。 您对此JSR有何期望？
JL：我希望它能在REST资源和POJO域对象之间产生良好的映射。 我希望我们能够实现JDB在RDBMS数据库和POJO之间所做的工作。 我除了以注释为中心的API之外，还对Restlet API进行了补充，Restlet API已经具有用于将REST资源映射到POJO的以类为中心的API。
我还认为，此JSR是调和REST和WS- *阵营的绝佳机会，因为这些注释也可以由Axis2和XFire等项目实现。
InfoQ：您能告诉我们一些依赖Restlet的项目吗？
JL：已经在各种规模的组织中的生产环境中部署了多个应用程序，其中包括Overstock.com，这是以折扣价出售商标的互联网领导者。 Restlet项目还用作涵盖REST体系结构样式的各种软件体系结构类的支持技术，例如在加利福尼亚大学欧文分校或INSA鲁昂工程学院。
我们还吃自己的狗食，并使用Restlet引擎运行所有网站。 考虑到我们收到的拒绝服务攻击的数量，我们对可扩展性充满信心。 最近，我们甚至发布了公开的基准测试，以证明这些性能。 我们与流行的Servlet容器处于同一水平，并期望在我们的下一个版本中胜过它们，它将在Glassfish的Grizzly NIO框架的基础上添加经过完全NIO优化的连接器。
InfoQ：在构建RESTful应用程序方面，您认为Java与其他语言相比如何？
JL：我们对流行的RESTful替代方案（如Rails或Django）的经验使我们认为Java / Restlet替代方案提出了对RESTful应用程序的更好，更高性能的支持。 Rails和Django并非在设计时就考虑了REST，这些概念仅在以后进行了改进。 与Restlets相比，这导致了更多的人为代码。 例如，Django不本地支持URI模板在URI和资源之间进行映射。 通过迫使RDBMS CRUD范例与REST / HTTP方法之间的不自然映射，Rails会产生不令人满意的结果，在这种情况下，您必须解决许多约束或适应面向资源的设计以适应Rails的世界观。 另一方面，Restlet不会强加任何持久性技术，而是让您自由定义资源，它们的表示形式以及它们如何映射到您的域对象或数据库。
InfoQ：您能在这方面对Rails的批评做些阐述吗？ 您认为其CRUD映射有什么不自然的地方？
JL：除了可以很好地映射到SQL SELECT和DELETE动词的GET和DELETE HTTP方法之外，我还发现Rails使用POST方法进行创建非常不幸。 在REST中创建的最佳方法是PUT，它也用于更新。 与POST相比，PUT的优势在于，如果操作失败，可以安全地重复操作，而POST则不会。
同样，资源列表是根据表名和数字行ID映射的，这可能并不总是实用的。 您不想失去对URI的控制，这些URI是应用程序用户界面的一部分，并且是REST中的基本概念。 在Restlet中，我们不对您的URI施加任何约束，并且您可以使用您熟悉的任何持久性技术（JPA批注的POJO，原始JDBC调用，对象数据库等）自由地映射资源和表示形式。
另一个较小的批评是，Rails鼓励使用笨拙的“; edit”后缀来访问资源的版本网页。 由于REST不鼓励通过URI参数规范非统一方法，因此这有点误导。 而是，他们应该使用浏览器先获取然后发布或放入的单独的Web表单资源。
InfoQ：您似乎已经在Restlet上投入了很多时间。 这是一个“业余”项目多少钱，您的公司期望从中获得多少商业成功？
JL：自成立以来，这个项目绝对不是业余爱好。 这是我在构建另一个重要的私人项目时感到需要的答案。 我相信专业开源，并希望Noelios Consulting提供的专业服务（支持计划，咨询）将使我们能够继续投入迄今为止所花的时间。
InfoQ：第一个版本之后您的路线图是什么？
JL：除了维护带有错误修复版本的1.0分支外，我们还将很快启动1.1分支。 我们想到的一些增强功能包括对WAR打包的支持（不需要XML描述符），通过XML描述符配置Restlet组件（便携式应用程序和虚拟主机的容器）的选项，以简化管理员的工作。 我们还需要完成几个连接器原型，一个基于Grizzly NIO框架核心的HTTP服务器连接器应为我们带来额外的可伸缩性和响应能力，以及两个基于JXTA虚拟套接字的HTTP连接器（一个客户端和一台服务器）。
我们还希望继续通过内容范围，摘要和WSSE身份验证等功能来加深对HTTP的支持。 我们还计划在2008年将Restlet API提交给JCP。这可能是弃用并逐步淘汰Servlet API的好机会。
InfoQ：非常感谢您的宝贵时间！
JéromeLouvel是Noelios Consulting的软件架构师和创始人。 他在欧洲和北美拥有8年以上的软件版本和咨询经验。 他对Java，REST，语义Web和业务流程集成特别感兴趣。
杰罗姆鲍威尔 是犹太人吗
499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
