在說restful風格的API之前，我們要先了解什么是rest。什么是restful。最后才是restful風格的API！
PS（REST：是一組架構約束條件和原則，REST是Roy Thomes Fielding在他2000年的博士論文中提出的。Roy Thomas Fielding是HTTP協議(v1.0和v1.1)的主要設計者、Apache服務器作者之一、Apache基金會第一任主席。）
什么是REST？
REST不是”rest”這個單詞，而是幾個單詞的縮寫 REpresentation State Transfer，直接翻譯：表現層狀態轉移，這個翻譯不太好理解。網上找到一個比較通俗的說法是：URL定位資源，用HTTP動詞（GET，POST，DELETE，PUSH等）描述操作 。REST最大的幾個特點為：資源、統一接口、URI和無狀態。
什么是Restful？
Restful基於REST構建的API就是Restful風格。
為什么使用Restful？
(1). 有的團隊之前一直使用JSP作為表現層，但是這樣的技術限制了他們的開發效率，他們需要將前端組給出靜態html頁面轉換為jsp頁面，並且寫一些js代碼，甚至是一些前端代碼。這樣會嚴重限制他們的開發效率，也不能讓后端組專注於業務功能的開發，所以目前越來越多的互聯網公司開始實行前后端分離。
(2). 近年隨着移動互聯網的發展，各種類型的客戶端層出不窮，Restful可以通過一套統一的接口為PC、微信(H5)、IOS和Android提供服務，這樣的接口不需要前端樣式，只提供數據。
Restful 是目前最流行的 API 設計規范，用於 Web 數據接口的設計。
下面才開始進入正題，如何設計Restful風格的API。
如何設計Restful風格的API
RestfulAPI就是由后台(SERVER端)來提供接口，前端來調用。前端調用API向后台發起HTTP請求，后台響應請求將處理結果反饋給前端。也就是說Restful 是典型的基於HTTP的協議。那么RESTful API有哪些特征呢？
(1).Resource資源，首先是弄清楚資源的概念。資源就是網絡上的一個實體、一段文本、一張圖片或者一首歌曲。資源總是要通過一種載體來反應它的內容。文本可以用TXT，也可以用HTML或者XML、圖片可以用JPG格式或者PNG格式，JSON是現在最常用的資源表現形式。
(2).統一接口。Restful風格的數據元操作CRUD(create,read,update,delete)分別對應HTTP方法：GET用來獲取資源，POST用來新建資源(也可以用於更新資源)，PUT用來更新資源，DELETE用來刪除資源，這樣就統一了數據操作的接口。
(3).HTTP狀態碼，在REST中都有特定的意義：200，201，202，204，400，401，403，500。比如401表示用戶身份認證失敗，403表示你驗證身份通過了，但這個資源你不能操作。
(4). 無狀態。所謂無狀態即所有的資源都可以URI定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而變化。
Restful 是典型的基於HTTP的協議，HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應，在請求結束后，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。前面一次請求與后面一次請求沒有必然的聯系，所以是無狀態的。
下面介紹如何設計出易於理解和使用的 API。
一、URL 設計
1.1 動詞 + 賓語
RESTful 的核心思想就是，客戶端發出的數據操作指令都是"動詞 + 賓語"的結構。比如，GET /articles這個命令，GET是動詞，/articles是賓語。
1.2 動詞的覆蓋
有些客戶端只能使用GET和POST這兩種方法。服務器必須接受POST模擬其他三個方法（PUT、PATCH、DELETE）。
這時，客戶端發出的 HTTP 請求，要加上X-HTTP-Method-Override屬性，告訴服務器應該使用哪一個動詞，覆蓋POST方法。
1.3 賓語必須是名詞
賓語就是 API 的 URL，是 HTTP 動詞作用的對象。它應該是名詞，不能是動詞。比如，/articles這個 URL 就是正確的，而下面的 URL 不是名詞，所以都是錯誤的。
1.4 復數 URL
既然 URL 是名詞，那么應該使用復數，還是單數？這沒有統一的規定，但是常見的操作是讀取一個集合，比如GET /articles（讀取所有文章），這里明顯應該是復數。
為了統一起見，建議都使用復數 URL，比如GET /articles/2要好於GET /article/2。
1.5 避免多級 URL
常見的情況是，資源需要多級分類，因此很容易寫出多級的 URL，比如獲取某個作者的某一類文章。除了第一級，其他級別都用查詢字符串表達。
二、狀態碼
2.1 狀態碼必須精確
客戶端的每一次請求，服務器都必須給出回應。回應包括 HTTP 狀態碼和數據兩部分。HTTP 狀態碼就是一個三位數，分成五個類別。這五大類總共包含100多種狀態碼，覆蓋了絕大部分可能遇到的情況。每一種狀態碼都有標准的（或者約定的）解釋，客戶端只需查看狀態碼，就可以判斷出發生了什么情況，所以服務器應該返回盡可能精確的狀態碼。API 不需要1xx狀態碼，下面介紹其他四類狀態碼的精確含義。
2.2 2xx 狀態碼
200狀態碼表示操作成功，但是不同的方法可以返回更精確的狀態碼。
POST返回201狀態碼，表示生成了新的資源；DELETE返回204狀態碼，表示資源已經不存在。
此外，202 Accepted狀態碼表示服務器已經收到請求，但還未進行處理，會在未來再處理，通常用於異步操作。
2.3 3xx 狀態碼
API 用不到301狀態碼（永久重定向）和302狀態碼（暫時重定向，307也是這個含義），因為它們可以由應用級別返回，瀏覽器會直接跳轉，API 級別可以不考慮這兩種情況。
API 用到的3xx狀態碼，主要是303 See Other，表示參考另一個 URL。它與302和307的含義一樣，也是"暫時重定向"，區別在於302和307用於GET請求，而303用於POST、PUT和DELETE請求。收到303以后，瀏覽器不會自動跳轉，而會讓用戶自己決定下一步怎么辦。
2.4 4xx 狀態碼
4xx狀態碼表示客戶端錯誤，主要有下面幾種。
400 Bad Request：服務器不理解客戶端的請求，未做任何處理。
401 Unauthorized：用戶未提供身份驗證憑據，或者沒有通過身份驗證。
403 Forbidden：用戶通過了身份驗證，但是不具有訪問資源所需的權限。
404 Not Found：所請求的資源不存在，或不可用。
2.5 5xx 狀態碼
5xx狀態碼表示服務端錯誤。一般來說，API 不會向用戶透露服務器的詳細信息，所以只要兩個狀態碼就夠了。
500 Internal Server Error：客戶端請求有效，服務器處理時發生了意外。
503 Service Unavailable：服務器無法處理請求，一般用於網站維護狀態。
三、服務器回應
3.1 不要返回純本文
API 返回的數據格式，不應該是純文本，而應該是一個 JSON 對象，因為這樣才能返回標准的結構化數據。所以，服務器回應的 HTTP 頭的Content-Type屬性要設為application/json。客戶端請求時，也要明確告訴服務器，可以接受 JSON 格式，即請求的 HTTP 頭的ACCEPT屬性也要設成application/json。
3.2 發生錯誤時，不要返回 200 狀態碼
有一種不恰當的做法是，即使發生錯誤，也返回200狀態碼，把錯誤信息放在數據體里面，這張做法實際上取消了狀態碼，這是完全不可取的。正確的做法是，狀態碼反映發生的錯誤，具體的錯誤信息放在數據體里面返回。
3.3 提供鏈接
API 的使用者未必知道，URL 是怎么設計的。一個解決方法就是，在回應中，給出相關鏈接，便於下一步操作。這樣的話，用戶只要記住一個 URL，就可以發現其他的 URL。這種方法叫做 HATEOAS。
上面就是一些關於restful風格的API的說明了，希望對你有幫助！
走前別忘了加個關注呦......