RESTful

REST（英文：Representational State Transfer，簡稱REST）描述了一個架構樣式的網路系統，比如 web 應用程序。它首次出現在 2000 年 Roy Fielding 的博士論文中，Roy Fielding是 HTTP 規範的主要編寫者之一。在目前主流的三種Web服務交互方案中，REST相比於SOAP（Simple Object Access protocol，簡單對象訪問協議）以及XML-RPC更加簡單明了，無論是對URL的處理還是對Payload的編碼，REST都傾向於用更加簡單輕量的方法設計和實現。值得注意的是REST並沒有一個明確的標準，而更像是一種設計的風格。

REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。

Web 應用程序最重要的 REST 原則是，客戶端和伺服器之間的交互在請求之間是無狀態的。從客戶端到伺服器的每個請求都必須包含理解請求所必需的信息。如果伺服器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用伺服器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。

在伺服器端，應用程序狀態和功能可以分為各種資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有：應用程序對象、資料庫記錄、演演算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個唯一的地址。所有資源都共享統一的介面，以便在客戶端和伺服器之間傳輸狀態。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是應用程序狀態的引擎，資源表示通過超鏈接互聯。

另一個重要的 REST 原則是分層系統，這表示組件無法了解它與之交互的中間層以外的組件。通過將系統知識限制在單個層，可以限制整個系統的複雜性，促進了底層的獨立性。

當 REST 架構的約束條件作為一個整體應用時，將生成一個可以擴展到大量客戶端的應用程序。它還降低了客戶端和伺服器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。REST 簡化了客戶端和伺服器的實現。

RESTful的關鍵是定義可表示流程元素/資源的對象。在REST中，每一個對象都是通過URL來表示的，對象用戶負責將狀態信息打包進每一條消息內，以便對象的處理總是無狀態的。

RESTful的第二大問題是組合管理及流程綁定。企業對正規的（基於SOAP）SOA最大的反對聲之一便是，這種等級的發現和綁定靈活性不足以適應複雜性。

有兩個Java框架可以幫助構建RESTful Web服務。erome Louvel和Dave Pawson開發的Restlet（見參考資料）是輕量級的。它實現針對各種RESTful系統的資源、表示、連接器和媒體類型之類的概念，包括Web服務。在Restlet 框架中，客戶端和伺服器都是組件。組件通過連接器互相通信。該框架最重要的類是抽象類Uniform及其具體的子類Restlet，該類的子類是專用類，比如Application、Filter、Finder、Router和Route。這些子類能夠一起處理驗證、過濾、安全、數據轉換以及將傳入請求路由到相應資源等操作。Resource類生成客戶端的表示形式。

JSR-311是Sun Microsystems的規範，可以為開發RESTful Web服務定義一組Java API。Jersey是對JSR-311的參考實現。

JSR-311提供一組註解，相關類和介面都可以用來將Java對象作為Web資源展示。該規範假定HTTP是底層網路協議。它使用註釋提供URI和相應資源類之間的清晰映射，以及HTTP方法與Java對象方法之間的映射。API支持廣泛的HTTP實體內容類型，包括HTML、XML、JSON、GIF、JPG等。它還將提供所需的插件功能，以允許使用標準方法通過應用程序添加其他類型。

RESTful Web 服務和動態 Web 應用程序在許多方面都是類似的。有時它們提供相同或非常類似的數據和函數，儘管客戶端的種類不同。例如，在線電子商務分類網站為用戶提供一個瀏覽器界面，用於搜索、查看和訂購產品。如果還提供 Web 服務供公司、零售商甚至個人能夠自動訂購產品，它將非常有用。與大部分動態 Web 應用程序一樣，Web 服務可以從多層架構的關注點分離中受益。業務邏輯和數據可以由自動客戶端和 GUI 客戶端共享。惟一的不同點在於客戶端的本質和中間層的表示層。此外，從數據訪問中分離業務邏輯可實現資料庫獨立性，並為各種類型的數據存儲提供插件能力。

圖 1 展示了自動化客戶端，包括 Java 和各種語言編寫的腳本，這些語言包括 Python、Perl、Ruby、PHP 或命令行工具，比如 curl。在瀏覽器中運行且作為 RESTful Web服務消費者運行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都屬於此列，因為它們都代表用戶以自動化樣式運行。自動化 Web 服務客戶端在 Web 層向 Resource Request Handler 發送 HTTP 響應。客戶端的無狀態請求在頭部包含方法信息，即 POST、GET、PUT 和 DELETE，這又將映射到 Resource Request Handler 中資源的相應操作。每個請求都包含所有必需的信息，包括 Resource Request Handler 用來處理請求的憑據。

從 Web 服務客戶端收到請求之後，Resource Request Handler 從業務邏輯層請求服務。Resource Request Handler 確定所有概念性的實體，系統將這些實體作為資源公開，並為每個資源分配一個惟一的 URI。但是，概念性的實體在該層是不存在的。它們存在於業務邏輯層。可以使用 Jersey 或其他框架（比如 Restlet）實現 Resource Request Handler，它應該是輕量級的，將大量職責工作委託給業務層。

Ajax 和 RESTful Web 服務本質上是互為補充的。它們都可以利用大量 Web 技術和標準，比如 HTML、JavaScript、瀏覽器對象、XML/JSON 和 HTTP。當然也不需要購買、安裝或配置任何主要組件來支持 Ajax 前端和 RESTful Web 服務之間的交互。RESTful Web 服務為 Ajax 提供了非常簡單的 API 來處理伺服器上資源之間的交互。

圖 1 中的 Web 瀏覽器客戶端作為 GUI 的前端，使用表示層中的 Browser Request Handler 生成的 HTML 提供顯示功能。Browser Requester Handler 可以使用 MVC 模型（JSF、Struts 或 Spring 都是 Java 的例子）。它從瀏覽器接受請求，從業務邏輯層請求服務，生成表示並對瀏覽器做出響應。表示供用戶在瀏覽器中顯示使用。表示不僅包含內容，還包含顯示的屬性，比如 HTML 和 CSS。

業務規則可以集中到業務邏輯層，該層充當表示層和數據訪問層之間的數據交換的中間層。數據以域對象或值對象的形式提供給表示層。從業務邏輯層中解耦 Browser Request Handler 和 Resource Request Handler 有助於促進代碼重用，並能實現靈活和可擴展的架構。此外，由於將來可以使用新的 REST 和 MVC 框架，實現它們變得更加容易，無需重寫業務邏輯層。

數據訪問層提供與數據存儲層的交互，可以使用 DAO 設計模式或者對象-關係映射解決方案（如 Hibernate、OJB 或 iBatis（隨著開發團隊轉投Google Code旗下，ibatis3.x正式更名為Mybatis））實現。作為替代方案，業務層和數據訪問層中的組件可以實現為 EJB 組件，並取得 EJB 容器的支持，該容器可以為組件生命周期提供便利，管理持久性、事務和資源配置。但是，這需要一個遵從 Java EE 的應用伺服器（比如 JBoss），並且可能無法處理 Tomcat。該層的作用在於針對不同的數據存儲技術，從業務邏輯中分離數據訪問代碼。數據訪問層還可以作為連接其他系統的集成點，可以成為其他 Web 服務的客戶端。

數據存儲層包括資料庫系統、LDAP 伺服器、文件系統和企業信息系統（包括遺留系統、事務處理系統和企業資源規劃系統）。使用該架構，您可以開始看到 RESTful Web 服務的力量，它可以靈活地成為任何企業數據存儲的統一 API，從而向以用戶為中心的 Web 應用程序公開垂直數據，並自動化批量報告腳本。

RESTFUL特點包括：

1、每一個URI代表1種資源；

2、客戶端使用GET、POST、PUT、DELETE4個表示操作方式的動詞對服務端資源進行操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源；

3、通過操作資源的表現形式來操作資源；

4、資源的表現形式是XML或者HTML；

5、客戶端與服務端之間的交互在請求之間是無狀態的，從客戶端到服務端的每個請求都必須包含理解請求所必需的信息。