原文轉自前端路上，轉載請註明出處：http://refined-x.com/2017/09/22/RESTful學習及應用/
RESTful是什麼
RESTful是一種API架構，符合REST設計原則的API都可以被稱爲RESTful，REST的全稱是Representational State Transfer。
REST的核心原則是後端將資源發佈爲URI，前端通過URI訪問資源，並通過HTTP動詞表示要對資源進行的操作，典型的RESTful API長這樣：
POST /artical //增加一篇文章 DELETE /artical/1 //刪除id爲1的文章 PUT /artical/1 //修改id爲1的文章 GET /articals/1 //查詢id爲1的文章
這裏需要明確一個概念：資源，後端提供的所有內容都可以被定義爲資源，前端用戶的一切行爲，本質都是與一系列後端資源互動的結果。從這個角度來講，前端的意義就是連接用戶與資源，使用戶能以最簡單的方式調度後端資源，並將調度結果以用戶最容易接受的方式呈現出來。
爲什麼使用RESTful
前後端分離的本質是前後端以API爲界限進行開發解耦，所以前後端分離的副產品是大量的API，採用RESTful架構可以讓API的表現力更強，更易於被理解；對於接口開發來說，RESTful風格也更易於擴展，這對於大型項目非常重要。
RESTful是無狀態的，因此無論前端是什麼設備，前端是什麼狀態，都可以無差別的請求資源，有利於後端實現分佈式。
RESTful允許前端索取指定格式的信息，因此可以實現一套統一的API服務於不同的前端設備。
如何構建RESTful API
一、每個網址代表一種資源，網址中只能有名詞
網址僅用來表示資源的名稱，而不包括操作，因此只能由名詞組成；但有些資源可能自帶操作屬性，比如轉賬，這時候我們應該將轉賬看成一種服務（名詞），將轉賬的其他信息作爲參數傳遞
二、對於資源的操作類型由HTTP動詞表示
常用的四種HTTP動詞以及對應的SQL操作。
GET（SELECT）：從服務器取出資源（一項或多項）。
POST（CREATE）：在服務器新建一個資源。
PUT（UPDATE）：在服務器更新資源（客戶端提供改變後的完整資源）
DELETE（DELETE）：從服務器刪除資源。
三、統一的返回結果
針對不同操作，服務器向用戶返回的結果應該符合以下規範。
GET /collection：返回資源對象的列表（數組） GET /collection/resource：返回單個資源對象 POST /collection：返回新生成的資源對象 PUT /collection/resource：返回完整的資源對象 PATCH /collection/resource：返回完整的資源對象 DELETE /collection/resource：返回一個空文檔
四、返回正確的狀態碼
常用狀態碼
200 ：服務器成功返回用戶請求的數據 400 ：用戶發出的請求有錯誤 401 ：表示用戶沒有權限 403 : 表示用戶得到授權（與401錯誤相對），但訪問被禁止的 404 ：用戶發出的請求針對的是不存在的記錄 500 ：服務器發生錯誤，用戶無法判斷髮出的請求是否成功
五、允許通過HTTP內容協商
客戶端可以通過Accept頭請求一種特定格式的表述，服務端則通過Content-Type告訴客戶端資源的表述形式。若服務器不支持，它應該返回一個HTTP 406響應，表示拒絕處理該請求。
通常項目中最常用的還是直接預定爲JSON格式。
web端的應用
目前最流行的web端AJAX類庫當屬axios，axios與RESTful完美兼容，主要體現在以下幾個方面。
axios將HTTP動詞直接封裝爲方法，正好對應RESTful的API風格，在RESTful架構中使用起來非常方便
axios.post(`/artical`, params) axios.delete(`/artical/1`, params) axios.put(`/artical/1`, params) axios.get(`/artical/1`, params)
而且axios的返回數據包括響應正文和狀態碼等信息，配合攔截器很容易實現對RESTful API錯誤碼的統一處理。
//錯誤處理 axios.interceptors.response.use(function(response) { return response; }, function(error) { if (error.response) { switch (error.response.status) { case 400: break; case 401: break; case 403: break; ... } } });
更多axios內容參考這裏。
最後
其實RESTful的絕大多數內容都是規範推薦的做法，沒有什麼新東西，只不過前幾年後端MVC盛行的時期，沒有這麼重的API開發需求，在這方面就一切從簡了，近來趕上前後端分離的東風，API設計又被大家重視起來了，重回規範的RESTful相當於讓大家見識了一下當年規範制定者們的遠見卓識，就像小時候不聽話的孩子在長大的某一天裏突然想起來長輩曾經的教誨一樣。