RESTFUL API

http://www.runoob.com/w3cnote/restful-architecture.html

https://www.ibm.com/developerworks/cn/webservices/0907_rest_soap/

respresentational state transfer

表現層狀態轉移

REST  一種風格，符合這種風格的api就是RESTFUL API

具體包括 

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
  • 使用-或_來讓URI可讀性更好
  • 使用/來表示層級關係
  • 使用?來過濾資源
  • 使用,;來表示同級資源的關係

2 統一資源接口

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

3 

資源的表述

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

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

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

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

在URI裏邊帶上版本號

服務器端不該該保存會話狀態

 

4  資源的連接 

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

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

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

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

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

5狀態的轉移

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

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

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

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

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

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

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

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