RESTful是目前最流行的API設計規範，它是用於Web資料介面的設計。從字面可以看出，他是Rest式的介面，所以我們先了解下什麼是Rest。

REST與技術無關，它代表的是一種軟體架構風格，REST它是 Representational State Transfer的簡稱，中文的含義是: "表徵狀態轉移" 或 "表現層狀態轉化"。它是基於HTTP、URI、XML、JSON等標準和協議，支援輕量級、跨平臺、跨語言的架構設計。

一. 理解為什麼要使用RESTful API設計規範？

在很久以前，工作時間長的同學肯定經歷過使用velocity語法來編寫html模板程式碼，也就是說我們的前端頁面放在伺服器端那邊進行編譯的，更準確的可以理解為 "前後端沒有進行分離"，那麼在那個時候，頁面、資料及模板渲染操作都是放在伺服器端進行的，但是這樣做有一個很大的缺點是: 後期維護比較麻煩，前端開發人員還必須掌握velocity相關的語法。因此為了解決這個問題慢慢就出現了前後端分離的思想: 即後端負責資料介面, 前端負責資料渲染, 前端只需要請求下api介面拿到資料，然後再將資料顯示出來。因此後端開發人員需要設計api介面，因此為了統一規範: 社群就出現了 RESTful API 規範，其實該規範很早就有的，只是最近慢慢流行起來，RESTful API 可以通過一套統一的介面為所有web相關提供服務，實現前後端分離。

二. Rest設計原則

那麼怎麼樣可以設計成REST的架構規範呢? 需要符合如下的一些原則：

1. 每一個URI代表一種資源;
2. 同一種資源有多種表現形式(xml/json);
3. 所有的操作都是無狀態的。
4. 規範統一介面。
5. 返回一致的資料格式。
6. 可快取(客戶端可以快取響應的內容)。

符合上述REST原則的架構方式被稱作為 RESTful 規範。

理解為什麼所有的操作需要無狀態呢?

http請求本身是無狀態的，它是基於 client-server 架構的，客戶端向伺服器端發的每一次請求都必須帶有充分的資訊能夠讓伺服器端識別到，請求的一些資訊通常會包含在URL的查詢引數中或header中，伺服器端能夠根據請求的各種引數, 不需要儲存客戶端的狀態, 直接將資料返回給客戶端。無狀態的優點是：可以大大提高伺服器端的健狀性和可擴充套件性。客戶端可以通過token來標識會話狀態。從而可以讓該使用者一直保持登入狀態。

理解規範統一的介面

Rest介面約束定義為: 資源識別；請求動作；響應資訊; 它表示通過uri表示出要操作的資源，通過請求動作(http method)標識要執行的操作，通過返回的狀態碼來表示這次請求的執行結果。

可能看上面的解釋還不夠理解，下面我通過自己的理解來解釋下上面的具體含義; 比如說，我在未使用Rest規範之前，我們可能有 增刪改查 等介面，因此我們會設計出類似這樣的介面: /xxx/newAdd (新增介面), /xxx/delete(刪除介面), /xxx/query (查詢介面), /xxx/uddate(修改介面)等這樣的。增刪改查有四個不同的介面，維護起來可能也不好，因此如果我們現在使用Restful規範來做的話，對於開發設計來說可能就只需要一個介面就可以了，比如設計該介面為 /xxx/apis 這樣的一個介面就可以了，然後請求方式(method)有 GET--查詢(從伺服器獲取資源); POST---新增(從伺服器中新建一個資源); PUT---更新(在伺服器中更新資源)，DELETE---刪除(從伺服器刪除資源)，PATCH---部分更新(從伺服器端更新部分資源) 等這些方式來做，也就是說我們使用RESTful規範後，我們的介面就變成了一個了，要執行增刪改查操作的話，我們只需要使用不同的請求動作(http method)方式來做就可以了，然後伺服器端返回的資料也可以是相同的，只是我們前端會根據狀態碼來判斷請求成功或失敗的狀態值來判斷。具體有那些狀態碼我們下面會講解到。

理解返回一致的資料格式

伺服器端返回的資料格式可以是XML、或json. 或者直接返回狀態碼的方式。比如返回錯誤的格式json資料如下:

{
    "code": 401,
    "status": "error",
    "message": '使用者沒有許可權',
    "data": null
}

返回正確的資料格式的json資料一般可以為如下:

{
    "code": 200,
    "status": "success",
    "data": [{
        "userName": "tugenhua",
        "age": 31
    }]
}

三. URL及引數設計規範

1. uri設計規範

1) uri末尾不需要出現斜槓/
2) 在uri中使用斜槓/是表達層級關係的。
3) 在uri中可以使用連線符-, 來提升可讀性。
比如 http://xxx.com/xx-yy 比 http://xxx.com/xx_yy中的可讀性更好。
4) 在uri中不允許出現下劃線字元_.
5) 在uri中儘量使用小寫字元。
6) 在uri中不允許出現副檔名. 比如介面為 /xxx/api, 不要寫成 /xxx/api.php 這樣的是不合法的。
7) 在uri中使用複數形式。
具體可以看：（https://blog.restcase.com/7-rules-for-rest-api-uri-design/）

在RESTful架構中，每個uri代表一種資源，因此uri設計中不能使用動詞，只能使用名詞，並且名詞中也應該儘量使用複數形式。使用者應該使用相應的http動詞 GET、POST、PUT、PATCH、DELETE等操作這些資源即可。

那麼在我們未使用RESTful規範之前，我們是如下方式來定義介面的，形式是不固定的，並且沒有統一的規範。比如如下形式:

http://xxx.com/api/getallUsers; // GET請求方式，獲取所有的使用者資訊
http://xxx.com/api/getuser/1;   // GET請求方式，獲取標識為1的使用者資訊
http://xxx.com/api/user/delete/1 // GET、POST 刪除標識為1的使用者資訊
http://xxx.com/api/updateUser/1  // POST請求方式 更新標識為1的使用者資訊
http://xxx.com/api/User/add      // POST請求方式，新增新的使用者

如上我們可以看到，在未使用Restful規範之前，介面形式是不固定的，沒有統一的規範，下面我們來看下使用RESTful規範的介面如下，兩者之間對比下就可以看到各自的優點了。

http://xxx.com/api/users;     // GET請求方式 獲取所有使用者資訊
http://xxx.com/api/users/1;   // GET請求方式 獲取標識為1的使用者資訊
http://xxx.com/api/users/1;   // DELETE請求方式 刪除標識為1的使用者資訊
http://xxx.com/api/users/1;   // PATCH請求方式，更新標識為1的使用者部分資訊
http://xxx.com/api/users;     // POST請求方式 新增新的使用者

如上我們可以看到，增刪改成我們都是使用同一個api介面，只是請求的方式 GET(查詢)、POST(新增)、DELETE(刪除)、PACTH(部分更新)來代表的是增刪改查操作的方式。然後開發獲取到該請求的header頭部資訊，就可以知道是什麼方式來請求資料的了。

2. HTTP請求規範

GET (SELECT): 查詢；從伺服器取出資源.
POST(CREATE): 新增; 在伺服器上新建一個資源。
PUT(UPDATE): 更新; 在伺服器上更新資源(客戶端提供改變後的完整資源)。
PATCH(UPDATE): 更新；在伺服器上更新部分資源(客戶端提供改變的屬性)。
DELETE(DELETE): 刪除; 從伺服器上刪除資源。

3. 引數命名規範

引數推薦採用下劃線命名的方式。比如如下demo:

http://xxx.com/api/today_login // 獲取今天登入的使用者。
http://xxx.com/api/today_login&sort=login_desc // 獲取今天登入的使用者、登入時間降序排序。

四. http狀態碼相關的

狀態碼範圍

客戶端的每一次請求, 伺服器端必須給出迴應，迴應一般包括HTTP狀態碼和資料兩部分。

1xx: 資訊，請求收到了，繼續處理。
2xx: 代表成功. 行為被成功地接收、理解及採納。
3xx: 重定向。
4xx: 客戶端錯誤，請求包含語法錯誤或請求無法實現。
5xx: 伺服器端錯誤.

2xx 狀態碼

200 OK [GET]: 伺服器端成功返回使用者請求的資料。
201 CREATED [POST/PUT/PATCH]: 使用者新建或修改資料成功。
202 Accepted 表示一個請求已經進入後臺排隊(一般是非同步任務)。
204 NO CONTENT -[DELETE]: 使用者刪除資料成功。

4xx狀態碼

400：Bad Request - [POST/PUT/PATCH]: 使用者發出的請求有錯誤，伺服器不理解客戶端的請求，未做任何處理。
401: Unauthorized; 表示使用者沒有許可權(令牌、使用者名稱、密碼錯誤)。
403：Forbidden: 表示使用者得到授權了，但是訪問被禁止了, 也可以理解為不具有訪問資源的許可權。
404：Not Found: 所請求的資源不存在，或不可用。
405：Method Not Allowed: 使用者已經通過了身份驗證, 但是所用的HTTP方法不在它的許可權之內。
406：Not Acceptable: 使用者的請求的格式不可得(比如使用者請求的是JSON格式，但是隻有XML格式)。
410：Gone - [GET]: 使用者請求的資源被轉移或被刪除。且不會再得到的。
415: Unsupported Media Type: 客戶端要求的返回格式不支援，比如，API只能返回JSON格式，但是客戶端要求返回XML格式。
422：Unprocessable Entity: 客戶端上傳的附件無法處理，導致請求失敗。
429：Too Many Requests: 客戶端的請求次數超過限額。

5xx 狀態碼

5xx 狀態碼錶示伺服器端錯誤。

500：INTERNAL SERVER ERROR; 伺服器發生錯誤。
502：閘道器錯誤。
503: Service Unavailable 伺服器端當前無法處理請求。
504：閘道器超時。

五. 統一返回資料格式

RESTful規範中的請求應該返回統一的資料格式。對於返回的資料，一般會包含如下欄位:

1) code: http響應的狀態碼。
2) status: 包含文字, 比如：'success'(成功), 'fail'(失敗), 'error'(異常) HTTP狀態響應碼在500-599之間為 'fail'; 在400-499之間為 'error', 其他一般都為 'success'。 對於響應狀態碼為 1xx, 2xx, 3xx 這樣的可以根據實際情況可要可不要。

當status的值為 'fail' 或 'error'時，需要新增 message 欄位，用於顯示錯誤資訊。

3) data: 當請求成功的時候, 返回的資料資訊。 但是當狀態值為 'fail' 或 'error' 時，data僅僅包含錯誤原因或異常資訊等。

返回成功的響應JSON格式一般為如下:

{
    "code": 200,
    "status": "success",
    "data": [{
        "userName": "tugenhua",
        "age": 31
    }]
}

返回失敗的響應json格式為如下:

{
    "code": 401,
    "status": "error",
    "message": '使用者沒有許可權',
    "data": null
}