RESTful基礎詳解

一、基礎定義。

1.1 全稱定義

        REST全稱是Representational State Transfer，中文為：表述性狀態轉移。

1.2 歷史背景

       它首次出現在 2000 年 Roy Fielding 的博士論文中，他是 HTTP 規範的主要編寫者之一。他在論文中他這麼設計的目的是，在符合架構原理的前提下，理解和評估以網路為基礎的軟體架構設計，得到一個功能好、效能好、事宜通訊的架構。REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 RESTful。

1.3 專業術語解釋

       1.3.1 資源與url

       REST全稱是表述性狀態轉移，其實就是資源。任何事物，只要有被引用到的必要，它就是一個資源。比如：一個人的身高、體重、肺活量（具體）；一個人的個性（抽象）。在我們看來這些都可以被稱為資源。然而當我們利用網路進行查詢的時候，就必須通過一個唯一表示來進行訪問。這個唯一標識就是URL。URI既可以看成是資源的地址，也可以看成是資源的名稱。例如：https://mp.csdn.net/postedit

        1.3.2 統一資源介面

      RESTful應該遵守同一資源介面原則。統一介面包含了一組，受限的預定義操作，不論什麼樣的資源，都是使用相同的介面，進行資源訪問。介面應該使用標準的HTTP方法：get、pur和post。並遵循這些方法的語義。如果按照http的語義來進行暴露資源，那麼介面就會擁有安全性和冪等性的特性。例如get和head方式都是安全的，無論請求多少次都不會改變伺服器的狀態。而get、head、pur和delete請求都是冪等性的。無論對資源操作多少次，結果都是一樣的，後面的請求並不會產生比第一次更多的影響。

冪等性：就是使用者對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點選而產生了副作用。舉個最簡單的例子，那就是支付，使用者購買商品使用約支付，支付扣款成功，但是返回結果的時候網路異常，此時錢已經扣了，使用者再次點選按鈕，此時會進行第二次扣款，返回結果成功，使用者查詢餘額返發現多扣錢了，流水記錄也變成了兩條。這就不是冪等性。

      1.3.3 資源的表述

      客戶端可以通過http方法獲取資源，但確切的說，其實客戶端只是獲取的資源的表述。可以有多種表述(或成為表現、表示)形式，在客戶端和服務端之間傳送的也是資源的表述，而不是資源本身。例如文字資源可以採用html、xml、json等格式，圖片可以使用PNG或JPG展現出來。

        1.3.4 資源的連結

       超媒體即應用狀態引擎（hypermedia as the engine of application state）瀏覽Web網頁時，從一個連線跳到一個頁面，再從另一個連線跳到另外一個頁面，就是利用了超媒體的概念：把一個個把資源連結起來。就要求在表述格式裡邊加入連結來引導客戶端。很多人在設計RESTful架構時，使用很多時間來尋找漂亮的URI，而忽略了超媒體。所以，應該多花一些時間來給資源的表述提供連結，而不是專注於"資源的CRUD"。

       1.3.5 狀態的轉移

       無狀態通訊原則，並不是說客戶端應用不能有狀態，而是指服務端不應該儲存客戶端狀態。

       1.3.6 應用狀態和資源狀態

實際上，狀態應該區分應用狀態和資源狀態，客戶端負責維護應用狀態，而服務端維護資源狀態。客戶端與服務端的互動必須是無狀態的，並在每一次請求中包含處理該請求所需的一切資訊。服務端不需要在請求間保留應用狀態，只有在接受到實際請求的時候，服務端才會關注應用狀態。這種無狀態通訊原則，使得服務端和中介能夠理解獨立的請求和響應。在多次請求中，同一客戶端也不再需要依賴於同一伺服器，方便實現高可擴充套件和高可用性的服務端。但有時候我們會做出違反無狀態通訊原則的設計，例如利用Cookie跟蹤某個服務端會話狀態，常見的像J2EE裡邊的JSESSIONID。這意味著，瀏覽器隨各次請求發出去的Cookie是被用於構建會話狀態的。

當然，如果Cookie儲存的是一些伺服器不依賴於會話狀態即可驗證的資訊（比如認證令牌），這樣的Cookie也是符合REST原則的。

1.4 簡單定義

RESTful架構：

   （1）每一個URI代表一種資源；

   （2）客戶端和伺服器之間，傳遞這種資源的某種表現層；

   （3）客戶端通過四個HTTP動詞，對伺服器端資源進行操作，實現"表現層狀態轉化"。

關於RESTful API設計指南：下面有一篇文章已經寫的非常詳細。

點選：   RESTful API設計指南