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）實現。做爲替代方案，業務層和數據訪問層中的組件能夠實現爲 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最大的反對聲之一即是，這種等級的發現和綁定靈活性不足以適應複雜性。