專訪Restlet框架首席開發者Jrome Louvel

專訪Restlet框架首席開發者Jrome Louvel[@more@]來自：infoq

最近Restlet框架釋出了它的1.0版。Jérome Louve是Java框架Restlet的領導開發者，近來記者有機會和Jérome Louvel進行了一次對話，本次談話的主題討論了Restlet存在的原因、在Java Web服務框架中的REST支援、Ruby on Rails、對JSR 311的期望以及Restlet的路線圖。

記者：你能給我們簡單地介紹下Restlet的目標嗎？

Jérome Louvel（以下簡稱JL）：Restlet是一個Java下的輕量級REST框架。透過擁抱REST（REST是一種Web架構風格）它模糊了Web 站點和Web服務之間的界限，從而幫助開發人員構建Web應用。每一個主要的REST概念（REST concept）都有一個對應的Java類。你的REST化的Web設計和你的程式碼之間的對映是非常簡單直接的。

Restlet是一個以CDDL或GPL釋出的開源專案。該專案包含一個Restlet API，一個引用實現（Noelios Restlet引擎）以及一套擴充套件。

記者：你為什麼會覺得有必要建立另一種框架？難道Servlet API還不夠好用嗎？

JL：Servlet AIP在1998年釋出，從那個時候起它的核心設計一直沒有很大的變化。它是Java EE的眾多API中最成功的一個，但是它的幾個設計缺陷和一些限制損害了它。舉個例子，URI模式和它的處理者（handler）之間的對映是受限制的，而且其配置都集中在一個配置檔案中。還有，他把socket流的控制直接交給了應用系統開發人員，Servlet容器阻礙了我們充分使用NIO特性對IO 操作進行最佳化。最後，他對一些HTTP特性，例如快取、內容協商以及內容壓縮支援的不好。這對開發人員來說是件痛苦的事，因為這阻礙了他們將精力集中在應用系統相關的程式碼上。

另一個主要問題是，Java EE Stack中新的HTTP客戶端API的缺少。JDK的HttpURLConnection類很難用，而且許多HTTP特性都不支援，比如為內容協商而表達的客戶端選擇等。人們經常需要依賴第三方HTTP客戶端API突破這些限制。但是，HttpURLConnection不支援NIO。

2005年，我看到了超越這些限制的機會：在REST原則下設計一個新的API。第一次，我們有了統一Web應用客戶端和伺服器端的機會，這個 API完全支援NIO並能讓開發人員程式設計控制Web容器、聯結器（connector）等，而且不需要經常性的依賴XML描述符就能部署應用系統。

記者：你怎麼看在別的框架中對REST的支援（例如Axis2，或者CXF/XFire）？

JL：我想這些支援非常有效，但是作用非常有限。我的主要觀點是設計這些專案是為了符合WS-*/SOAP Stack，它們與REST世界並不非常契合。在REST世界裡，定義了一個全新的範例：面向資源的設計，而非透過遠端方法呼叫這樣的範例。

例如Axis2僅僅支援GET和POST兩種HTTP方法，它需要遠端方法的傳遞需要一個URI引數。這在REST中式不允許的，這種做法也不能被稱之為REST化。

XFire1.2不支援REST，但是它釋出了一個專案用於將POJO對映到REST化的Web服務。這有點類似最近釋出的JSR-311，此JSR試圖基於一套annotation和助手類標準化這種對映。

記者：你是JSR 311專家組的成員，能否對JSR 311做一下展望？

JL：我期望它能在REST資源和POJO領域物件之間實現一個完好的對映。就像JPA在關聯式資料庫和POJO之間實現了很好的對映那樣，我們也希 望這個JSR能做到像JPA那樣。我希望以annotation為中心的API能夠相當符合（complimentary）Restlet API，後者已經是一個將REST資源對映到POJO的以類為中心的API了。

這些annotation也能被像Axis2和XFire這樣的專案實現，我認為這個JSR給了REST和WS-*陣營一個達成和解的機會。

記者：你能告訴我們一些基於Restlet的專案嗎？

JL：有幾個不同規模的組織已經部署並應用了這樣的應用系統，包括Overstock.com，這是一個線上購物方面的Internet領導者。 Restlet專案也被作為支援技術用在覆蓋REST構架風格的不同軟體構架類別中。例如在加州Irvine大學，以及在INSA Rouen工程學院的使用。

我們自己的網站也是用Restlet引擎構建的。考慮到我們受到拒絕服務（denial of service）的攻擊量，我們對我們系統的可伸縮性很自信。最近我們還發布了一個公用基準以證明了其效能品質。我們與流行的Servlet容器處在同一水平線上，而且有望在下一個加入完全的NIO最佳化的聯結器（基於Glassfish的Grizzly NIO框架）的版本中比後者表現更為優異。

記者：在構建REST化的應用系統中，能否比較一下Java和其他語言有何不同？

JL：流行的REST化技術，例如Rails或者Django這些技術的經驗告訴我們，Java/Restlet這樣的技術在支援REST化的應用中會有更好更高的效能表現。Rails和Django開始的設計並沒有考慮到REST，REST的這些概念只是在後來被加進去的。相比Restlet，這導致了很多做作的（contrived）程式碼。以Django為例，它並不天然支援在URI和資源之間對映的URI模板。而Rails強迫在關聯式資料庫和對資料的CRUD操作間使用一種不自然的對映，REST/HTTP方法導致一種令人不滿意的結果：開發人員不得不在各種限制下工作，或者採用自己的面向資源的設計去迎合Rails。而Restlet不強迫你使用任何持久化技術，它讓你自由的定義你的資源及其特定的表現形式（representation），以及它們怎麼被對映到你的領域物件或你的資料庫。

記者：你能更詳細的解釋下你剛才對Rails的批評嗎? 你認為它的CRUD對映什麼地方不夠自然?

JL：除了GET和DETLET這樣的HTTP方法可以很好的對映到SQL的SELECT和DELETE外，我還發現Rails將HTTP的 POST方法用來進行建立行為，這很不幸。在REST中，對於建立行為最好的方法是使用PUT，它也可以用於更新。PUT比POST優越的地方是如果操作行為失敗了，它可以很安全的重複操作，而POST不行。

還有，資源列表是基於表名和行記錄的數字型id對映的，在實踐中這並不總是可行的。你不想失去對你的URI的控制，而URI既是應用系統使用者介面的一部分，又是REST最基本的概念之一。在Restlet中，我們並不對你的URI強加任何限制，你可以自由的使用任一持久化技術（例如JPA的 annotation化POJO，純JDBC呼叫，物件資料庫等等）在你的資源和表現形式（representation）之間進行對映。

我對Rails的另一個小小的批評是，Rails鼓勵使用笨拙的“;edit”字尾訪問一個資源的編輯Web頁面。這有點誤導，REST並不鼓勵使用URI引數的非一致方法，應該使用分隔的Web表單資源，這樣瀏覽器可以使用GET、POST或者PUT方法。

記者：你好像在Restlet上花了不少時間。這個業餘專案佔用了你多少時間，你的公司期望能從這個專案中得到多大的商業成就？

JL：從開始這個專案就不是作為一個業餘產品啟動的。當我構建另一個很重要的私人專案是我就感覺到了對它的需要。我相信專業的開源專案，也希望Noelios Consulting能提供的專業服務（如支援計劃，顧問服務）能讓我們繼續投入更多的精力。

記者：第一版釋出之後的路線圖是什麼？

JL：除了維護1.0版修改bug外，我們還將很快啟動1.1版。一些我們曾想過的對WAR包（不再需要XML描述符）的增強將被加進來。使用者可以選擇透過一個XML描述符配置Restlet元件（可移植的應用系統和虛擬主機容器）從而簡化管理員的工作。我們還有幾個聯結器原型要實現，一個是基於 Grizzly NIO框架的HTTP伺服器聯結器，它將帶來更多的可伸縮性和響應（responsiveness）。另外兩個HTTP聯結器是基於JX他的虛擬 socket（一個客戶機和一個伺服器）。

我們還想更深入的支援HTTP特性，例如內容範圍（content range），Digest和WSSE授權。我們還計劃在2008年將Restlet API提交給JCP。這有利於逐漸替代Servlet API。
Jérome Louvel簡介：Jérome Louvel是一位軟體架構師，它是Noelios Consulting公司的創始人。在軟體版本（Software edition）和諮詢方面有超過8年的工作經驗，它常年工作在歐洲和北美洲。他對Java、REST、語義網以及商業過程整合有濃厚的興趣。