RESTful架構詳解

1.什麼是REST

REST全稱是Representantional State Transfer，中文譯爲表述（表徵）性狀態轉移。「REST指的是一組架構約束條件和原則。」若是一個架構符合REST的約束條件和原則，就稱其爲RESTful架構。

2.理解RESTful

理解RESTful架構，須要理解epresentational State Transfer這個詞組究竟是什麼意思，它的每個詞都有些什麼涵義。下面結合REST原則，圍繞資源展開討論，從資源的定義、獲取、表述、關聯、狀態變遷等角度，列舉一些關鍵概念並加以解釋。
2.1資源與URI
REST全稱表述性狀態轉移，到底是的是什麼的表述？其實指的就是資源。任何事物，只要有被引用的必要，它就是一個資源。資源能夠是實體（如手機號），也能夠是一個抽象概念（如價值）。
要讓一個資源能夠被識別，須要有個惟一標識，在Web中這個惟一標識就是URI（Uniform Resource Identifier）。URI能夠當作是資源的地址，也能夠當作資源的名稱。如某些信息沒有使用URI來表示，就不算是一個資源，只能算是資源的一些信息而已。URI的設計應遵循可尋址性原則，具備自描述性，須要在形式上給人以直覺上的關聯。
URI設計技巧：
使用_或-來讓URI可讀性更好
使用/來表示資源的層級關係
使用？來過濾資源
，或；能夠用來表示同級資源關係
2.2統一資源接口
RESTful架構應該遵循統一接口原則，統一接口包含一組受限的預約義操做，不論什麼樣的資源，都是經過使用相同的接口進行資源的訪問。接口應該使用標準的HTTP方法如GET，PUT和POST，並遵循這些方法的語義。
若是按照HTTP方法的語義來暴露資源，那麼接口將會擁有安全性和冪等性的特性。
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）- 服務端當前沒法處理請求
實踐中常見問題：
統一資源接口對URI有什麼指導意義?
統一資源接口要求使用標準的HTTP方法對資源進行操做，因此URI只應該來表示資源的名稱，而不該該包括資源的操做。通俗來講，URI不該該使用動做來描述。
若是GET請求增長計數器，這是否違反安全性?
安全性不表明請求不產生反作用，例如像不少API開發平臺，都對請求流量作限制。像github，就會限制沒有認證的請求每小時只能請求60次。 但客戶端不是爲了追求反作用而發出這些GET或HEAD請求的，產生反作用是服務端"自做主張"的。另外，服務端在設計時，也不該該讓反作用太大，由於客戶端認爲這些請求是不會產生反作用的。
直接忽視緩存可取嗎?
即便你按各個動詞的本來意圖來使用它們，你仍能夠輕易禁止緩存機制。 最簡單的作法就是在你的HTTP響應裏增長這樣一個報頭： Cache-control: no-cache。 可是，同時你也對失去了高效的緩存與再驗證的支持(使用Etag等機制)。 對於客戶端來講，在爲一個REST式服務實現程序客戶端時，也應該充分利用現有的緩存機制，以避免每次都從新獲取表示。
響應代碼的處理有必要嗎?
HTTP的響應代碼可用於應付不一樣場合，正確使用這些狀態代碼意味着客戶端與服務器能夠在一個具有較豐富語義的層次上進行溝通。
例如，201（「Created」）響應代碼代表已經建立了一個新的資源，其URI在Location響應報頭裏。 假如你不利用HTTP狀態代碼豐富的應用語義，那麼你將錯失提升重用性、加強互操做性和提高鬆耦合性的機會。若是這些所謂的RESTful應用必須經過響應實體才能給出錯誤信息，那麼SOAP就是這樣的了，它就可以知足了。
2.3資源的表述
上面提到，客戶端經過HTTP方法能夠獲取資源，是吧? 不，確切的說，客戶端獲取的只是資源的表述而已。 資源在外界的具體呈現，能夠有多種表述(或成爲表現、表示)形式，在客戶端和服務端之間傳送的也是資源的表述，而不是資源自己。 例如文本資源能夠採用html、xml、json等格式，圖片可使用PNG或JPG展示出來。資源的表述包括數據和描述數據的元數據，例如，HTTP頭"Content-Type" 就是這樣一個元數據屬性。
實踐上常見設計：
再URI裏面帶上版本號
使用URI後綴區分表述格式
如何處理不支持的表述格式：返回一個HTTP406響應，表示處理該請求。
2.4資源的連接
咱們知道REST是使用標準的HTTP方法來操做資源的，但僅僅所以就理解成帶CURD的Web數據庫架構就太過於簡單了。 這種反模式忽略了一個核心概念：「超媒體即應用狀態引擎（hypermedia as the engine of application state）」。 超媒體是什麼? 當你瀏覽Web網頁時，從一個鏈接跳到一個頁面，再從另外一個鏈接跳到另一個頁面，就是利用了超媒體的概念：把一個個資源連接起來。要達到這個目的，就要求在表述格式裏邊加入連接來引導客戶端。在《RESTful Web Services》一書中，做者把這種具備連接的特性成爲連通性。
2.5狀態轉移
咱們先來討論一下REST原則中的無狀態通訊原則。初看一下，好像自相矛盾了，既然無狀態，何來狀態轉移一說? 其實，這裏說的無狀態通訊原則，並非說客戶端應用不能有狀態，而是指服務端不該該保存客戶端狀態。
2.5.1應用狀態與資源狀態
實際上，狀態應該區分應用狀態和資源狀態，客戶端負責維護應用狀態，而服務端維護資源狀態。
客戶端與服務端的交互必須是無狀態的，並在每一次請求中包含處理該請求所需的一切信息。
服務端不須要在請求間保留應用狀態，只有在接受到實際請求的時候，服務端纔會關注應用狀態。
這種無狀態通訊原則，使得服務端和中介可以理解獨立的請求和響應。
在屢次請求中，同一客戶端也再也不須要依賴於同一服務器，方便實現高可擴展和高可用性的服務端。
但有時候咱們會作出違反無狀態通訊原則的設計，例如利用Cookie跟蹤某個服務端會話狀態，常見的像J2EE裏邊的JSESSIONID。
這意味着，瀏覽器隨各次請求發出去的Cookie是被用於構建會話狀態的。
固然，若是Cookie保存的是一些服務器不依賴於會話狀態便可驗證的信息（好比認證令牌），這樣的Cookie也是符合REST原則的。
2.5.2應用狀態的轉移
狀態轉移到這裏已經很好理解了， "會話"狀態不是做爲資源狀態保存在服務端的，而是被客戶端做爲應用狀態進行跟蹤的。客戶端應用狀態在服務端提供的超媒體的指引下發生變遷。服務端經過超媒體告訴客戶端當前狀態有哪些後續狀態能夠進入。 這些相似"下一頁"之類的連接起的就是這種推動狀態的做用——指引你如何從當前狀態進入下一個可能的狀態。
3總結
如今廣東XXX版本、XXX等項目中均使用傳統的RPC、SOAP方式的Web服務，而移動南方基地XXXX項目的後臺， 雖然採用了JSON格式進行交互，但仍是屬於RPC風格的。本文從資源的定義、獲取、表述、關聯、狀態變遷等角度， 試圖快速理解RESTful架構背後的概念。RESTful架構與傳統的RPC、SOAP等方式在理念上有很大的不一樣，但願本文能對各位理解REST有所幫助。