http://www.aiz8.cn/html/ROR/News/2007-8-20/ZhuanFang-Restlet-KuangJiaShouXiKaiFaZhe-Jrome-Louvel.html 專訪Restlet框架首席開發(fā)者Jérome Louvel 發(fā)布日期：2007-8-20 0:17:03 來源：ruby-lang.org.cn 作者：Stefan Tilkov譯者 宋瑋
最近Restlet框架發(fā)布了它的1.0版。JéromeLouve是Java框架Restlet的領(lǐng)導開發(fā)者，InfoQ的編輯Stefan Tikov有機會和JéromeLouvel進行了一次對話，本次談話的主題討論了Restlet存在的原因、在Java Web服務框架中的REST支持、Ruby onRails、對JSR 311的期望以及Restlet的路線圖。
InfoQ：你能給我們簡單地介紹下Restlet的目標嗎？
Jérome Louvel（以下簡稱JL）：Restlet是一個Java下的輕量級REST框架。通過擁抱REST（REST是一種Web架構(gòu)風格）它模糊了Web站點和Web服務之間的界限，從而幫助開發(fā)人員構(gòu)建Web應用。每一個主要的REST概念（REST concept）都有一個對應的Java類。你的REST化的Web設(shè)計和你的代碼之間的映射是非常簡單直接的。Restlet是一個以CDDL或GPL發(fā)布的開源項目。該項目包含一個Restlet API，一個引用實現(xiàn)（Noelios Restlet引擎）以及一套擴展。
InfoQ：你為什么會覺得有必要創(chuàng)建另一種框架？難道Servlet API還不夠好用嗎？
JL：Servlet AIP在1998年發(fā)布，從那個時候起它的核心設(shè)計一直沒有很大的變化。它是JavaEE的眾多API中最成功的一個，但是它的幾個設(shè)計缺陷和一些限制損害了它。舉個例子，URI模式和它的處理者（handler）之間的映射是受限制的，而且其配置都集中在一個配置文件中。還有，他把socket流的控制直接交給了應用系統(tǒng)開發(fā)人員，Servlet容器阻礙了我們充分使用NIO特性對IO操作進行優(yōu)化。最后，他對一些HTTP特性，例如緩存、內(nèi)容協(xié)商以及內(nèi)容壓縮支持的不好。這對開發(fā)人員來說是件痛苦的事，因為這阻礙了他們將精力集中在應用系統(tǒng)相關(guān)的代碼上。另一個主要問題是，Java EEStack中新的HTTP客戶端API的缺少。JDK的HttpURLConnection類很難用，而且許多HTTP特性都不支持，比如為內(nèi)容協(xié)商而表達的客戶端選擇等。人們經(jīng)常需要依賴第三方HTTP客戶端API突破這些限制。但是，HttpURLConnection不支持NIO。2005年，我看到了超越這些限制的機會：在REST原則下設(shè)計一個新的API。第一次，我們有了統(tǒng)一Web應用客戶端和服務器端的機會，這個API完全支持NIO并能讓開發(fā)人員編程控制Web容器、連接器（connector）等，而且不需要經(jīng)常性的依賴XML描述符就能部署應用系統(tǒng)。
InfoQ：你怎么看在別的框架中對REST的支持（例如Axis2，或者CXF/XFire）？
JL：我想這些支持非常有效，但是作用非常有限。我的主要觀點是設(shè)計這些項目是為了符合WS-*/SOAP Stack，它們與REST世界并不非常契合。在REST世界里，定義了一個全新的范例：面向資源的設(shè)計，而非通過遠程方法調(diào)用這樣的范例。例如Axis2僅僅支持GET和POST兩種HTTP方法，它需要遠程方法的傳遞需要一個URI參數(shù)。這在REST中式不允許的，這種做法也不能被稱之為REST化。XFire1.2不支持REST，但是它發(fā)布了一個項目用于將POJO映射到REST化的Web服務。這有點類似最近發(fā)布的JSR-311，此JSR試圖基于一套annotation和助手類標準化這種映射。
InfoQ：你是JSR 311專家組的成員，能否對JSR 311做一下展望？
JL：我期望它能在REST資源和POJO領(lǐng)域?qū)ο笾g實現(xiàn)一個完好的映射。就像JPA在關(guān)系數(shù)據(jù)庫和POJO之間實現(xiàn)了很好的映射那樣，我們也希望這個JSR能做到像JPA那樣。我希望以annotation為中心的API能夠相當符合（complimentary）Restlet API，后者已經(jīng)是一個將REST資源映射到POJO的以類為中心的API了。
這些annotation也能被像Axis2和XFire這樣的項目實現(xiàn)，我認為這個JSR給了REST和WS-*陣營一個達成和解的機會。
InfoQ：你能告訴我們一些基于Restlet的項目嗎？
JL：有幾個不同規(guī)模的組織已經(jīng)部署并應用了這樣的應用系統(tǒng)，包括Overstock.com，這是一個在線購物方面的Internet領(lǐng)導者。Restlet項目也被作為支持技術(shù)用在覆蓋REST構(gòu)架風格的不同軟件構(gòu)架類別中。例如在加州Irvine大學，以及在INSA Rouen工程學院的使用。我們自己的網(wǎng)站也是用Restlet引擎構(gòu)建的?？紤]到我們受到拒絕服務（denial of service）的攻擊量，我們對我們系統(tǒng)的可伸縮性很自信。最近我們還發(fā)布了一個公用基準以證明了其性能品質(zhì)。我們與流行的Servlet容器處在同一水平線上，而且有望在下一個加入完全的NIO優(yōu)化的連接器（基于Glassfish的Grizzly NIO框架）的版本中比后者表現(xiàn)更為優(yōu)異。
InfoQ：在構(gòu)建REST化的應用系統(tǒng)中，能否比較一下Java和其他語言有何不同？
JL：流行的REST化技術(shù)，例如Rails或者Django這些技術(shù)的經(jīng)驗告訴我們，Java/Restlet這樣的技術(shù)在支持REST化的應用中會有更好更高的性能表現(xiàn)。Rails和Django開始的設(shè)計并沒有考慮到REST，REST的這些概念只是在后來被加進去的。相比Restlet，這導致了很多做作的（contrived）代碼。以Django為例，它并不天然支持在URI和資源之間映射的URI模板。而Rails強迫在關(guān)系數(shù)據(jù)庫和對數(shù)據(jù)的CRUD操作間使用一種不自然的映射，REST/HTTP方法導致一種令人不滿意的結(jié)果：開發(fā)人員不得不在各種限制下工作，或者采用自己的面向資源的設(shè)計去迎合Rails。而Restlet不強迫你使用任何持久化技術(shù)，它讓你自由的定義你的資源及其特定的表現(xiàn)形式（representation），以及它們怎么被映射到你的領(lǐng)域?qū)ο蠡蚰愕臄?shù)據(jù)庫。
InfoQ：你能更詳細的解釋下你剛才對Rails的批評嗎? 你認為它的CRUD映射什么地方不夠自然?
JL：除了GET和DETLET這樣的HTTP方法可以很好的映射到SQL的SELECT和DELETE外，我還發(fā)現(xiàn)Rails將HTTP的POST方法用來進行創(chuàng)建行為，這很不幸。在REST中，對于創(chuàng)建行為最好的方法是使用PUT，它也可以用于更新。PUT比POST優(yōu)越的地方是如果操作行為失敗了，它可以很安全的重復操作，而POST不行。還有，資源列表是基于表名和行記錄的數(shù)字型id映射的，在實踐中這并不總是可行的。你不想失去對你的URI的控制，而URI既是應用系統(tǒng)用戶界面的一部分，又是REST最基本的概念之一。在Restlet中，我們并不對你的URI強加任何限制，你可以自由的使用任一持久化技術(shù)（例如JPA的annotation化POJO，純JDBC調(diào)用，對象數(shù)據(jù)庫等等）在你的資源和表現(xiàn)形式（representation）之間進行映射。我對Rails的另一個小小的批評是，Rails鼓勵使用笨拙的“;edit”后綴訪問一個資源的編輯Web頁面。這有點誤導，REST并不鼓勵使用URI參數(shù)的非一致方法，應該使用分隔的Web表單資源，這樣瀏覽器可以使用GET、POST或者PUT方法。
InfoQ：你好像在Restlet上花了不少時間。這個業(yè)余項目占用了你多少時間，你的公司期望能從這個項目中得到多大的商業(yè)成就？
JL：從開始這個項目就不是作為一個業(yè)余產(chǎn)品啟動的。當我構(gòu)建另一個很重要的私人項目是我就感覺到了對它的需要。我相信專業(yè)的開源項目，也希望Noelios Consulting能提供的專業(yè)服務（如支持計劃，顧問服務）能讓我們繼續(xù)投入更多的精力。
InfoQ：第一版發(fā)布之后的路線圖是什么？
JL：除了維護1.0版修改bug外，我們還將很快啟動1.1版。一些我們曾想過的對WAR包（不再需要XML描述符）的增強將被加進來。用戶可以選擇通過一個XML描述符配置Restlet組件（可移植的應用系統(tǒng)和虛擬主機容器）從而簡化管理員的工作。我們還有幾個連接器原型要實現(xiàn)，一個是基于GrizzlyNIO框架的HTTP服務器連接器，它將帶來更多的可伸縮性和響應（responsiveness）。另外兩個HTTP連接器是基于JXTA的虛擬socket（一個客戶機和一個服務器）。我們還想更深入的支持HTTP特性，例如內(nèi)容范圍（content range），Digest和WSSE授權(quán)。我們還計劃在2008年將Restlet API提交給JCP。這有利于逐漸替代Servlet API。
InfoQ：謝謝你抽出時間接受我們的采訪。
查看原文鏈接：Interview: Jérome Louvel about Restlet 作者簡介：Jérome Louvel是一位軟件架構(gòu)師，它是Noelios Consulting公司的創(chuàng)始人。在軟件版本（Software edition）和咨詢方面有超過8年的工作經(jīng)驗，它常年工作在歐洲和北美洲。他對Java、REST、語義網(wǎng)以及商業(yè)過程集成有濃厚的興趣。
http://www.matrix.org.cn/resource/article/2007-11-30/1312be72-9f14-11dc-bd16-451eadcf4db4.html
Restlet指南[Matrix社區(qū)試讀版] cleverpig 發(fā)表于 2007-11-30 15:15:48
作者:cleverpig 來源:Matrix 相關(guān)資源：http://www.restlet.org/documentation/1.0/tutorial http://www.restlet.org/about/introduction
摘要:當復雜核心化模式日趨強大之時，面向?qū)ο笤O(shè)計范例已經(jīng)不總是Web開發(fā)中的最佳選擇，Java開發(fā)者需要認識到這一點，并且在開發(fā)新的Web服務端或是 AJAX Web客戶端時開始思考更加RESTfully的設(shè)計。Restlet這個開源項目為那些要采用REST結(jié)構(gòu)體系來構(gòu)建應用程序的Java開發(fā)者提供了一個具體的解決方案。朋友們，下面就讓我們開始Restlet探索之旅吧！ 工具箱
關(guān)于本指南
本指南的翻譯工作經(jīng)過了Restlet社區(qū)的官方授權(quán)，cleverpig作為貢獻者完成了本文的翻譯和整理工作。在此發(fā)布Matrix社區(qū)試讀版的目的是為了讓更多的技術(shù)愛好者閱讀并提出翻譯中的不足之處，以提高本指南的質(zhì)量，以期修改后正式發(fā)布。
Servlet的限制: 在2003年末，Jetty Web容器的作者、Servlet規(guī)范的貢獻者：Greg Wilkins在其博客上對Servlet的問題進行了如下總計：
* 沒有對協(xié)議與應用之間的關(guān)系進行清洗的劃分。
* 由于在設(shè)計Servlet時存在對阻塞IO的假設(shè)，因此不能充分利用非阻塞NIO機制。
* 所有的Servlet Web容器對于某些應用來講是過度設(shè)計的。
他提出構(gòu)思新的API規(guī)范，使其能夠真實地脫離協(xié)議，并定義能夠暴露內(nèi)容和元數(shù)據(jù)的contentlets。這些想法就是Restlet項目創(chuàng)建的靈感源泉。在之后的文章中，Greg Wilkins解釋了為什么當前Servlet API限制非阻塞NIO API得到高效使用的詳細理由：這種傳統(tǒng)的用法針對每個HTTP請求都創(chuàng)建獨立的線程進行處理。并提出了他對下一代Servlet技術(shù)的設(shè)想。
另一個主要問題就是Servlet API鼓勵應用開發(fā)者在應用或者用戶會話級別直接將session狀態(tài)保存于內(nèi)存中，盡管這看上去不錯，但它造成了Servlet容器擴展性和高可用性的主要問題。為了克服這些問題，就必須實現(xiàn)復雜的負載均衡、session復制、持久化機制。這導致了可擴展性必然成為災難。
Restlet簡介——當復雜核心化模式日趨強大之時，面向?qū)ο笤O(shè)計范例已經(jīng)不總是Web開發(fā)中的最佳選擇，Java開發(fā)者需要認識到這一點，并且在開發(fā)新的Web服務端或是AJAX Web客戶端時開始思考更加RESTfully的設(shè)計。Restlet這個開源項目為那些要采用REST結(jié)構(gòu)體系來構(gòu)建應用程序的Java開發(fā)者提供了一個具體的解決方案。它的非常簡單易用的功能和RESTfully的Web框架，這使其成為了Web2.0開發(fā)中的又一利器。好吧，朋友們，下面就讓我們開始Restlet探索之旅吧！
評論：目前 Restlet 都是建在 Asyncweb, Jetty, Simple 等 webserver 之上, 如果有建在 Grizzly 上的會更好看. 至少希望看到有關(guān)的比較. 另外, Restlet 提出的概念和 Grizzly framework 現(xiàn)在所做的都很類似, 特別是 Glassfish V3 版本中提出 Grizzlet 的概念.
http://www.matrix.org.cn/resource/article/2008-03-04/990c1fb3-e9d0-11dc-91da-b599c3ba16ef.html
Restlet之AJAX實踐
摘要:在下面的實踐性指南中，我將以一個簡單的“微型blog”（microblog）為例詳細說明在Restlet中如何使用AJAX技術(shù)。。。 工具箱。在下面的實踐性指南中，我將以一個簡單的“微型blog”（microblog）為例詳細說明在Restlet中如何使用AJAX技術(shù)。預備知識：在編寫代碼之前，讓我們先來回顧一下有關(guān)restlet的知識（如果你不曾了解或者忘記的話）：
* RESTful是什么?
* 了解Restlet
* 如何使用Restlet?
* Restlet指南
* 如何使用db4o簡化持久化數(shù)據(jù)存儲?
* 如何在Prototype.js中使用JSON?
微型blog結(jié)構(gòu):
* Web client：web瀏覽器通過JSON協(xié)議以RESTful的方式（(GET/PUT/POST/DELETE)）調(diào)用后臺服務；
* 服務器端：利用db4o作為數(shù)據(jù)存儲服務提供者，并通過Restlet將數(shù)據(jù)暴露給web服務；
* 服務端處理過程：在Restlet中，Application接收到Request后將其分配給相應的Router，Router尋找相匹配的Resource類并實例化匹配好的Resource類、將Request傳送給它，Resource類對象處理Request并返回相應的表達法（representation）。
下載源代碼：microblog_sourcecode (application/x-zip, 2.3 MB, info)
資源鏈接： * Router * Application * Resource * db4o