RESTful概念理解

基礎

REST 定義了一組體系架構原則，您能夠根據這些原則設計以系統資源爲中心的 Web 服務，包括使用不一樣語言編寫的客戶端如何經過 HTTP 處理和傳輸資源狀態。

若是考慮使用它的 Web 服務的數量，REST 近年來已經成爲最主要的 Web 服務設計模型。 事實上，REST 對 Web 的影響很是大，因爲其使用至關方便，已經廣泛地取代了基於 SOAP 和 WSDL 的接口設計。

REST 這個概念於 2000 年由 Roy Fielding 在就讀加州大學歐文分校期間在學術論文「Architectural Styles and the Design of Network-based Software Architectures」（請參見參考資料以獲取此論文的連接）首次提出，他的論文中對使用 Web 服務做爲分佈式計算平臺的一系列軟件體系結構原則進行了分析，而其中提出的 REST 概念並無得到如今這麼多關注。 多年之後的今天，REST 的主要框架已經開始出現，但仍然在開發中，由於它已經被普遍接納到各個平臺中，例如經過 JSR-311 成爲了 Java™ 6 不可或缺的部分。

本文認爲，對於今天正在吸引如此多注意力的最純粹形式的 REST Web 服務，其具體實現應該遵循四個基本設計原則：

• 顯式地使用 HTTP 方法（GET、PUT、POST 、DELETE）。
• 無狀態。
• 公開目錄結構式的 URI。
• 傳輸 XML、JavaScript Object Notation (JSON)，或同時傳輸這二者。

參考：http://www.ibm.com/developerworks/cn/webservices/ws-restful/

 

RESTful 服務

REST 描述了可用來實現聯網系統的一種設計模型。REST 既不是一種技術也不是一種標準；它是用來經過 Web 公開資源的一種架構風格。RESTful 架構聽從如下幾個原則：
請求是客戶-服務器 式的，並很天然地使用一種基於拉的交互風格。對組件的使用會從服務器中拉出狀態的表示。
請求是無狀態的。每一個從客戶端到服務器端的請求都必須包含理解此請求所需的所有信息，並且不能利用服務器上所存儲的上下文。
REST 並不必定就意味着在中間層沒有任何狀態；爲實現對某資源的請求的這個狀態並不依賴於該狀態。
客戶機和服務器都聽從統一的接口。全部的資源均可經過 Web 擴展的 SOA 世界中的普通接口進行訪問 —— HTTP 及 HTTP 方法：GET、POST、PUT 和 DELETE。
客戶機與命名的資源進行交互。此係統由使用 URL（好比 HTTP URL）命名的資源組成。

REST 是表示 Web 中的服務的關鍵技術。REST 在公開基於數據的服務方面效果最好，理解這一點很是重要。這些數據服務進而能夠混合和匹配以便構建新的應用程序（一般稱爲 mashup）。以下的示例展現了客戶機是如何對待 RESTful 服務的。

用 http://<host>/customer：
GET：返回客戶列表
POST：建立客戶記錄

用 http://<host>/customer/roland：
GET：返回 Roland 客戶記錄
PUT：更新 Roland 記錄
DELETE：刪除 Roland 記錄

在本例中，所公開的資源是 Customer。此 Customer 用 URI /customer 表示。特定的客戶則經過在 Customer 以後追加標識符加以表示，例如 /customer/ims。HTTP 報頭方法定義了訪問此資源的意圖。

參考：https://www.ibm.com/developerworks/cn/web/i-zero1/

 

何爲 REST?

RESTful

REST (Representation State Transfer) ful 就是 fulfil（履行, 知足, 完成, 落實, 兌現, 實踐）

REST 是設計基於命名資源 — 例如，以 Uniform Resource Locators（URL）、Uniform Resource Identifiers（URI）和 Uniform Resource Names（URN）的形式 — 而非消息的鬆耦合 Web 應用程序的一種風格。REST 巧妙地藉助已經驗證過的成功的 Web 基礎設施 — HTTP。換句話說，REST 利用了 HTTP 協議的某些方面，例如 GET 和 POST 請求。這些請求能夠很好地映射到標準業務應用程序需求，諸如建立、讀取、更新和刪除（CRUD），如表 1 所示：

表 1. CRUD/HTTP 映射

應用程序任務	HTTP 命令
建立	POST
讀取	GET
更新	PUT
刪除	DELETE

請求就像是動詞，而資源就像是名詞，把二者相關聯就造成了對行爲的邏輯表達 — 例如， GET 這個文件，DELETE 那條記錄。

真正的 REST 之父 Roy Fielding 在他的博士畢業論文中陳述到：REST 「強調組件交互的可伸縮性、界面的廣泛性、獨立部署組件以及使用中間組件來減小交互延遲，加強安全性並封裝遺留系統」（參見 參考資料）。構建 RESTful 系統並不難，且這樣的系統具備高度的可伸縮性，同時與底層數據鬆散耦合；這樣的系統還能夠很好地利用緩存。

Web 上全部的東西（頁面、圖像等）本質上都是資源。而 REST 正是基於命名資源而非消息的，這就限制了底層技術的曝光，從而給應用程序設計中的鬆耦合提供了便利條件。例如，下面的 URL 在不暗示任何底層技術的狀況下，公開了資源：http://thediscoblog.com/2008/03/20/unambiguously-analyzing-metrics/。

該 URL 表示一個資源 — 一篇名爲 「Unambiguously analyzing metrics」 的文章。請求該資源就會調用 HTTP GET 命令。注意該 URL 是基於名詞的。基於動詞的版本（大概相似 http://thediscoblog.com/2008/03/20/getArticle?name=unambiguously-analyzing-metrics）會違反 REST 原則，由於它以 getArticle 的形式嵌套了一條消息。您也能夠設想經過 HTTP 的 POST 命令來發佈一個新資源，（好比說，一篇諸如 http://thediscoblog.com/2008/03/22/rest-is-good-for-you/ 的文章）。你還能夠設想用關聯的、基於動詞的 API — 如 createArticle?name=rest-is-good-for-you and deleteArticle?name=rest-is-good-for-you — 這樣的調用來攔截 HTTP GET 命令，並最大限度地忽略已有的（而且是成功的）HTTP 基礎設施。換句話說，它們不是 RESTful 風格。

REST 的魅力在於任何東西均可以成爲資源，且表示方法也能夠不一樣。在前面的例子中，資源爲一個 HTML 文件，所以，其響應多是 HTML 格式的。可是資源也能夠是一個 XML 文檔、序列化的對象或者 JSON 表示。其實，這些都可有可無。重要的是資源被命名了，而且與它通訊不會影響其狀態。不影響狀態是很重要的，由於無狀態的交互有利於可伸縮性。

它的價值在那裏？

引用達芬奇的一句名言 「簡潔就是終極複雜」。萬維網的實現很是簡單，而且無可置否地得到了成功。REST 正是利用了 Web 的簡單性，並所以造就了高度可伸縮的、鬆散耦合的系統，並且事實證實，這樣的系統很容易構建。

正如您所看到的，構建 RESTful 應用程序最難的部分在於肯定要公開的資源。解決了這個問題以後，再使用開源 Restlet 框架構建 RESTful Web 服務就是小菜一碟了。

http://www.ibm.com/developerworks/cn/education/java/j-rest/j-rest.html