RESTful

一種軟體架構風格，設計風格而不是标準，隻是提供了一組設計原則和限制條件。它主要用于用戶端和伺服器互動類的軟體。基于這個風格設計的軟體可以更簡潔，更有層次，更易于實作緩存等機制。

概述

編輯

REST（英文：Representational State Transfer，簡稱REST）描述了一個架構樣式的網絡系統，比如 web 應用程式。它首次出現在 2000 年 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的實作：RESTful Web 服務與 RPC 樣式的 Web 服務

了解了什麼是REST，我們再看看RESTful的實作。使用 RPC 樣式架構建構的基于 SOAP 的 Web 服務成為實作 SOA 最常用的方法。RPC 樣式的 Web 服務用戶端将一個裝滿資料的信封（包括方法和參數資訊）通過 HTTP 發送到伺服器。伺服器打開信封并使用傳入參數執行指定的方法。方法的結果打包到一個信封并作為響應發回用戶端。用戶端收到響應并打開信封。每個對象都有自己獨特的方法以及僅公開一個 URI 的 RPC 樣式 Web 服務，URI 表示單個端點。它忽略 HTTP 的大部分特性且僅支援 POST 方法。

由于輕量級以及通過 HTTP 直接傳輸資料的特性，Web 服務的 RESTful 方法已經成為最常見的替代方法。可以使用各種語言（比如 Java 程式、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax]）實作用戶端。RESTful Web 服務通常可以通過自動用戶端或代表使用者的應用程式通路。但是，這種服務的簡便性讓使用者能夠與之直接互動，使用它們的 Web 浏覽器建構一個 GET URL 并讀取傳回的内容。

在 REST 樣式的 Web 服務中，每個資源都有一個位址。資源本身都是方法調用的目标，方法清單對所有資源都是一樣的。這些方法都是标準方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。

在 RPC 樣式的架構中，關注點在于方法，而在 REST 樣式的架構中，關注點在于資源 —— 将使用标準方法檢索并操作資訊片段（使用表示的形式）。資源表示形式在表示形式中使用超連結互聯。

Leonard Richardson 和 Sam Ruby 在他們的著作 RESTful Web Services 中引入了術語 REST-RPC 混合架構。REST-RPC 混合 Web 服務不使用信封包裝方法、參數和資料，而是直接通過 HTTP 傳輸資料，這與 REST 樣式的 Web 服務是類似的。但是它不使用标準的 HTTP 方法操作資源。它在 HTTP 請求的 URI 部分存儲方法資訊。好幾個知名的 Web 服務，比如 Yahoo 的 Flickr API 和 Delicious API 都使用這種混合架構。

RESTful的實作：RESTful Web 服務的 Java 架構

有兩個 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的實作：建構 RESTful Web 服務的多層架構

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 應用程式公開垂直資料，并自動化批量報告腳本。

什麼是REST：結束語

REST 描述了一個架構樣式的互聯系統（如 Web 應用程式）。REST 限制條件作為一個整體應用時，将生成一個簡單、可擴充、有效、安全、可靠的架構。由于它簡便、輕量級以及通過 HTTP 直接傳輸資料的特性，RESTful Web 服務成為基于 SOAP 服務的一個最有前途的替代方案。用于 web 服務和動态 Web 應用程式的多層架構可以實作可重用性、簡單性、可擴充性群組件可響應性的清晰分離。開發人員可以輕松使用 Ajax 和 RESTful Web 服務一起建立豐富的界面。

RESTful的關鍵

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

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

參考資料