RESTFUL架構

一、什麼是REST：

　　REST全稱是Representational State Transfer，中文意思是表徵性狀態轉移。 它首次出如今2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規範的主要編寫者之一。 他在論文中提到："我這篇文章的寫做目的，就是想在符合架構原理的前提下，理解和評估以網絡爲基礎的應用軟件的架構設計，獲得一個功能強、性能好、適宜通訊的架構。REST指的是一組架構約束條件和原則。" 若是一個架構符合REST的約束條件和原則，咱們就稱它爲RESTful架構。

　　REST自己並無創造新的技術、組件或服務，而隱藏在RESTful背後的理念就是使用Web的現有特徵和能力， 更好地使用現有Web標準中的一些準則和約束。雖然REST自己受Web技術的影響很深， 可是理論上REST架構風格並非綁定在HTTP上，只不過目前HTTP是惟一與REST相關的實例。 因此咱們這裏描述的REST也是經過HTTP實現的REST。

二、如何理解RESTful架構：

要理解RESTful架構，須要理解Representational State Transfer這個詞組究竟是什麼意思，它的每個詞都有些什麼涵義。

下面咱們結合REST原則，圍繞資源展開討論，從資源的定義、獲取、表述、關聯、狀態變遷等角度，列舉一些關鍵概念並加以解釋。

• 資源與URI
• 統一資源接口
• 資源的表述
• 資源的連接
• 狀態的轉移

2.1資源與URI

　　REST全稱是表述性狀態轉移，那究竟指的是什麼的表述? 其實指的就是資源。任何事物，只要有被引用到的必要，它就是一個資源。資源能夠是實體(例如手機號碼)，也能夠只是一個抽象概念(例如價值) 。下面是一些資源的例子：

• 某用戶的手機號碼
• 某用戶的我的信息
• 最多用戶訂購的GPRS套餐
• 兩個產品之間的依賴關係
• 某用戶能夠辦理的優惠套餐
• 某手機號碼的潛在價值

　　要讓一個資源能夠被識別，須要有個惟一標識，在Web中這個惟一標識就是URI(Uniform Resource Identifier)。

　　URI既能夠當作是資源的地址，也能夠當作是資源的名稱。若是某些信息沒有使用URI來表示，那它就不能算是一個資源， 只能算是資源的一些信息而已。URI的設計應該遵循可尋址性原則，具備自描述性，須要在形式上給人以直覺上的關聯。這裏以github網站爲例，給出一些還算不錯的URI：

• https://github.com/git
• https://github.com/git/git
• https://github.com/git/git/blob/master/block-sha1/sha1.h
• https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
• https://github.com/git/git/pulls
• https://github.com/git/git/pulls?state=closed
• https://github.com/git/git/compare/master…next

下面讓咱們來看看URI設計上的一些技巧:

• 使用_或-來讓URI可讀性更好

曾經Web上的URI都是冰冷的數字或者無心義的字符串，但如今愈來愈多的網站使用_或-來分隔一些單詞，讓URI看上去更爲人性化。 例如國內比較出名的開源中國社區，它上面的新聞地址就採用這種風格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。

• 使用/來表示資源的層級關係

例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一個多級的資源， 指的是git用戶的git項目的某次提交記錄，又例如/orders/2012/10能夠用來表示2012年10月的訂單記錄。

• 使用?用來過濾資源

不少人只是把?簡單的當作是參數的傳遞，很容易形成URI過於複雜、難以理解。能夠把?用於對資源的過濾， 例如/git/git/pulls用來表示git項目的全部推入請求，而/pulls?state=closed用來表示git項目中已經關閉的推入請求， 這種URL一般對應的是一些特定條件的查詢結果或算法運算結果。

• ,或;能夠用來表示同級資源的關係

有時候咱們須要表示同級資源的關係時，可使用,或;來進行分割。例如哪天github能夠比較某個文件在隨意兩次提交記錄之間的差別，或許可使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca做爲URI。 不過，如今github是使用…來作這個事情的，例如/git/git/compare/master…next。

2.二、統一資源接口

RESTful架構應該遵循統一接口原則，統一接口包含了一組受限的預約義的操做，不論什麼樣的資源，都是經過使用相同的接口進行資源的訪問。接口應該使用標準的HTTP方法如GET，PUT和POST，並遵循這些方法的語義。

若是按照HTTP方法的語義來暴露資源，那麼接口將會擁有安全性和冪等性的特性，例如GET和HEAD請求都是安全的， 不管請求多少次，都不會改變服務器狀態。而GET、HEAD、PUT和DELETE請求都是冪等的，不管對資源操做多少次， 結果老是同樣的，後面的請求並不會產生比第一次更多的影響。

下面列出了GET，DELETE，PUT和POST的典型用法:

get

• 安全且冪等
• 獲取表示
• 變動時獲取表示（緩存）

• 200（OK） - 表示已在響應中發出

• 204（無內容） - 資源有空表示
• 301（Moved Permanently） - 資源的URI已被更新
• 303（See Other） - 其餘（如，負載均衡）
• 304（not modified）- 資源未更改（緩存）
• 400 （bad request）- 指代壞請求（如，參數錯誤）
• 404 （not found）- 資源不存在
• 406 （not acceptable）- 服務端不支持所需表示
• 500 （internal server error）- 通用錯誤響應
• 503 （Service Unavailable）- 服務端當前沒法處理請求

post

• 不安全且不冪等
• 使用服務端管理的（自動產生）的實例號建立資源
• 建立子資源
• 部分更新資源
• 若是沒有被修改，則不過更新資源（樂觀鎖）

• 200（OK）- 若是現有資源已被更改

• 201（created）- 若是新資源被建立
• 202（accepted）- 已接受處理請求但還沒有完成（異步處理）
• 301（Moved Permanently）- 資源的URI被更新
• 303（See Other）- 其餘（如，負載均衡）
• 400（bad request）- 指代壞請求
• 404 （not found）- 資源不存在
• 406 （not acceptable）- 服務端不支持所需表示
• 409 （conflict）- 通用衝突
• 412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的衝突）
• 415 （unsupported media type）- 接受到的表示不受支持
• 500 （internal server error）- 通用錯誤響應
• 503 （Service Unavailable）- 服務當前沒法處理請求

put

• 不安全但冪等
• 用客戶端管理的實例號建立一個資源
• 經過替換的方式更新資源
• 若是未被修改，則更新資源（樂觀鎖）

• 200 （OK）- 若是已存在資源被更改

• 201 （created）- 若是新資源被建立
• 301（Moved Permanently）- 資源的URI已更改
• 303 （See Other）- 其餘（如，負載均衡）
• 400 （bad request）- 指代壞請求
• 404 （not found）- 資源不存在
• 406 （not acceptable）- 服務端不支持所需表示
• 409 （conflict）- 通用衝突
• 412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的衝突）
• 415 （unsupported media type）- 接受到的表示不受支持
• 500 （internal server error）- 通用錯誤響應
• 503 （Service Unavailable）- 服務當前沒法處理請求

delete

• 不安全但冪等
• 刪除資源

• 200 （OK）- 資源已被刪除

• 301 （Moved Permanently）- 資源的URI已更改
• 303 （See Other）- 其餘，如負載均衡
• 400 （bad request）- 指代壞請求
• 404 （not found）- 資源不存在
• 409 （conflict）- 通用衝突
• 500 （internal server error）- 通用錯誤響應
• 503 （Service Unavailable）- 服務端當前沒法處理請求

下面咱們來看一些實踐中常見的問題:

• post和put用於建立資源時有什麼區別?

post和put在建立資源的區別在於，所建立的資源的名稱(URI)是否由客戶端決定。 例如爲個人博文增長一個java的分類，生成的路徑就是分類名/categories/java，那麼就能夠採用PUT方法。不過不少人直接把post、get、put、delete直接對應上CRUD，例如在一個典型的rails實現的RESTful應用中就是這麼作的。

我認爲，這是由於rails默認使用服務端生成的ID做爲URI的緣故，而很多人就是經過rails實踐REST的，因此很容易形成這種誤解。

• 客戶端不必定都支持這些HTTP方法吧?

的確有這種狀況，特別是一些比較古老的基於瀏覽器的客戶端，只能支持get和post兩種方法。

在實踐上，客戶端和服務端均可能須要作一些妥協。例如rails框架就支持經過隱藏參數_method=DELETE來傳遞真實的請求方法， 而像Backbone這樣的客戶端MVC框架則容許傳遞_method傳輸和設置X-HTTP-Method-Override頭來規避這個問題。

• 統一接口是否意味着不能擴展帶特殊語義的方法?

統一接口並不阻止你擴展方法，只要方法對資源的操做有着具體的、可識別的語義便可，並可以保持整個接口的統一性。

像WebDAV就對HTTP方法進行了擴展，增長了LOCK、UPLOCK等方法。而github的API則支持使用PATCH方法來進行issue的更新，

例如：

PATCH /repos/:owner/:repo/issues/:number

2.三、資源的表述

　　上面提到，客戶端經過HTTP方法能夠獲取資源，是吧? 不，確切的說，客戶端獲取的只是資源的表述而已。 資源在外界的具體呈現，能夠有多種表述(或成爲表現、表示)形式，在客戶端和服務端之間傳送的也是資源的表述，而不是資源自己。 例如文本資源能夠採用html、xml、json等格式，圖片可使用PNG或JPG展示出來。

資源的表述包括數據和描述數據的元數據，例如，HTTP頭"Content-Type" 就是這樣一個元數據屬性。

那麼客戶端如何知道服務端提供哪一種表述形式呢?

答案是能夠經過HTTP內容協商，客戶端能夠經過Accept頭請求一種特定格式的表述，服務端則經過Content-Type告訴客戶端資源的表述形式。

以github爲例，請求某組織資源的json格式的表述形式:

假如github也可以支持xml格式的表述格式，那麼結果就是這樣的:

 

2.四、資源的連接

　　咱們知道REST是使用標準的HTTP方法來操做資源的，但僅僅所以就理解成帶CURD的Web數據庫架構就太過於簡單了。

這種反模式忽略了一個核心概念："超媒體即應用狀態引擎（hypermedia as the engine of application state）"。 超媒體是什麼?

當你瀏覽Web網頁時，從一個鏈接跳到一個頁面，再從另外一個鏈接跳到另一個頁面，就是利用了超媒體的概念：把一個個把資源連接起來.

要達到這個目的，就要求在表述格式裏邊加入連接來引導客戶端。在《RESTful Web Services》一書中，做者把這種具備連接的特性成爲連通性。下面咱們具體來看一些例子。

下面展現的是github獲取某個組織下的項目列表的請求，能夠看到在響應頭裏邊增長Link頭告訴客戶端怎麼訪問下一頁和最後一頁的記錄。 而在響應體裏邊，用url來連接項目全部者和項目地址。

又例以下面這個例子，建立訂單後經過連接引導客戶端如何去付款。

上面的例子展現瞭如何使用超媒體來加強資源的連通性。不少人在設計RESTful架構時，使用不少時間來尋找漂亮的URI，而忽略了超媒體。因此，應該多花一些時間來給資源的表述提供連接，而不是專一於"資源的CRUD"。

 

2.五、狀態的轉移

實際上，狀態應該區分應用狀態和資源狀態，客戶端負責維護應用狀態，而服務端維護資源狀態。

客戶端與服務端的交互必須是無狀態的，並在每一次請求中包含處理該請求所需的一切信息。

服務端不須要在請求間保留應用狀態，只有在接受到實際請求的時候，服務端纔會關注應用狀態。

這種無狀態通訊原則，使得服務端和中介可以理解獨立的請求和響應。

在屢次請求中，同一客戶端也再也不須要依賴於同一服務器，方便實現高可擴展和高可用性的服務端。

但有時候咱們會作出違反無狀態通訊原則的設計，例如利用Cookie跟蹤某個服務端會話狀態，常見的像J2EE裏邊的JSESSIONID。

這意味着，瀏覽器隨各次請求發出去的Cookie是被用於構建會話狀態的。

固然，若是Cookie保存的是一些服務器不依賴於會話狀態便可驗證的信息（好比認證令牌），這樣的Cookie也是符合REST原則的。

狀態轉移到這裏已經很好理解了， "會話"狀態不是做爲資源狀態保存在服務端的，而是被客戶端做爲應用狀態進行跟蹤的。客戶端應用狀態在服務端提供的超媒體的指引下發生變遷。服務端經過超媒體告訴客戶端當前狀態有哪些後續狀態能夠進入。

這些相似"下一頁"之類的連接起的就是這種推動狀態的做用——指引你如何從當前狀態進入下一個可能的狀態。