• 概念：restful風格是一種軟體架構風格，設計風格，而不是標準，只是提供了一種設計原則和和約束條件，它主要用於客戶端和服務端用於互動類的軟體。基於這個風格設計軟體可以更簡潔，更有層次，更易於實現快取等機制。它本身沒有什麼使用性其核心價值在於設計出符合restful風格的網路介面。
• REST這個詞，源於HTTP協議（1.0版和1.1版）的主要設計者表於2000年的博士論文《架構風格與基於網路的軟體架構設計》REST它是 Representational State Transfer的縮寫，表示表述性狀態轉移，這個說明比較晦澀抽象，難以理解。接下來拆開解釋。首先這句話省略了主語“表述性”其實指的是“資源”的“表述性”；其次，要先理解一個重要的概念:資源的表述；最後再體會狀態轉移。
• 資源：REST是面向資源的，資源是網路上的一個實體，可以是一個檔案、一張影象、一首歌曲、甚至是一種服務。資源可以設計得很抽象，但只要是具體資訊，就可以是資源，因為資源的本質是一串二進位制資料。並且每個資源必須有URL，通過URL來找到資源。
• 表述：資源在某個特定時刻的狀態說明被稱為表述（representation），表述由資料和描述資料的元資料（例如HTTP報文）組成。資源的表述有多種格式，這些格式也被稱為MIME型別，例如文字的txt格式、影象的png格式、視訊的mk格式等。一個資源可以有多種表述，例如伺服器響應一個請求返回的資源可以是JSON格式的資料，也可以是XML格式的資料。
• 表述性狀態轉移
  ：表述性狀態轉移的目的是操作資源，通過轉移和控制資源的表述就能實現此目的。例如客戶端可以向伺服器傳送GET請求，伺服器將資源的表述轉移到客戶端；客戶端也可以向伺服器傳送POST請求，傳遞表述改變伺服器中的資源狀態。

下面是對於restful風格的具體規範寫法:
一.API的url
Url是用來定位資源的，要跟操作區分開，不能使用動詞，要使用名詞。
下面示例中的get，create，search等動詞都不應該出現在resful風格的後端介面路徑中。比如：
/api/getUser
/api/createUser
/api/serarchResult
/api/deleteUsers
當我們需要對單個使用者進行操作時，根據操作的方式不同可能需要以下介面：
/api/getUser(用來獲取某個使用者的資訊，，還需要以引數的方式傳入使用者id資訊)
/api/updateUser（更新使用者資訊）
/api/deleteUser(刪除使用者資訊)
/api/resetUser（重置使用者資訊）
可能在更新不同資訊是使用不同的介面：
/api/updateUserName
/api/updateUserEamil
/api/updateUser
總結

• url中不應該出現任何表示操作的動詞，連結只能用於對應資源
• Url中應該單複數區分，推薦實踐中永遠用複數，比如get /api/users用於獲取使用者列表，如果需要獲取單個使用者，可以傳入id.
• 按照資源邏輯層級，對url進行巢狀，比如一個成員屬於團隊，而這個團隊又屬於多個團隊中的一個，那個獲取某個成員的介面可能是這樣：get /api/teams/123/members/234 表示獲取123團隊下的成員234的成員資訊，按照類似的規則可以寫出以下介面：
  1./api/teams (獲取團隊列表)
  2./api/teams/123 (獲取名為123的團隊)
  3./api/teams/123/memers (獲取名為123團隊中的成員列表)

二.API,的請求方法
我們常用的請求方法就是GET，POST，PUT,DELETE,PATCH
接下來我們主要講解一下 PUT , PATCH DELETE ，UPDATE(PUT,PATCH)
1.UPDATE(PUT,PATCH)
udpate用於資源的更新，用於更新的http方法有兩個PUT 和 PATHCH,他們都應當被實現為冪等方法，及多次同樣的更新請求應當對 伺服器產生同樣的副作用。
PUT 用於更新資源的全部資訊，在請求的body中需要傳入修改後的全部資源主體；
PATCH用於區域性更新，在body中傳入需要改動的資源欄位
PATCH 的作用在於如果一個資源中有很多欄位，在進行區域性修改時，只需要傳入需要修改的欄位即可。否則在PUT狀態下你不得不將整個資源全部發送給伺服器，造成網路資源的極大浪費。
2.DELETE
資源的刪除，相應的請求http方法就是DELETE。這個也應該被實現一個冪等的方法，如DELETE /api/users/123 用於刪除伺服器上id為123的資源，多次請求產生的副作用都是，伺服器上id為123的資源不存在。
https://blog.csdn.net/qq_35075909/article/details/91522242

三：過濾
Rest風格的介面地址，表示的可能是單個資源，也可能是資源集合，當我們需要訪問資源集合時，設計良好的介面應當接收引數允許只返回某些只滿足特定條件的資源列表。
只提供關鍵詞進行搜尋，以及排序
Get api/users?Keywords=123&sort=createtime
支援根據欄位進行過濾
Get api/users?Gender=1
當我們熟悉這且遵循這樣的規範後，基本就可以看到一個rest風格的介面如何使用這個介面進行crud操作了。比如下面這個介面就表示搜尋id為123的圖書館的書，並且書的資訊裡面包含關鍵詞【game】，返回前十條滿足條件的結果。
GET api/libararies/123/books?Keyword=game&sort=price&limit=10&offset=0

其他規範：
規則1：url結尾不應愛包含（/）
規則2：正斜槓分割符（/）必須用來指定層級關係
規則3：不得在url中使用下劃線（_）
規則4：url路徑中全部使用小寫字母
規則5：使用_或-來讓URI可讀性更好 例如國內某知名開源中國社群，它上面的新聞地址就採用這種風格，http://www.oschina.net/news/38119/oschina-translate-reward-plan 。
規則6：使用？來過濾資源 很多人把？只當做引數傳遞，很容易造成url過於複雜，難以理解。可以把？用於對資源的過濾，例如/git/git/pulls用來表示git專案的所有推入請求，而/pulls?State=closed用來表示git專案中已經關閉的推入請求，這種url通常是對應一些特定條件的查詢結果或演算法運算結果。

四：使用http狀態碼處理錯誤
http狀態碼提供70個出錯，我們只需要10左右：
200 -OK --一切正常，表示成功
201-OK--資源成功建立
202請求已被接收
204 操作已執行，但是沒有返回資料
301資源被移除
303 重定向
304 資源沒有被修改
400 引數錯誤(缺少，格式不匹配)
401 未授權
403 訪問受限，訪問過期
404 訪問資源，伺服器沒找到
405 不允許的http方法
415 不支援的資料型別
429 請求過多被限制
500 系統內部錯誤
501 介面未實現

五：統一資源介面
Restful架構應該遵循統一介面原則，統一介面包含了一組受限的預定義的操作，無論什麼樣的資源，都是通過使用相同的介面進行資源訪問，介面應該使用標準的http方法如：GET. POST PUT ,並遵循這些方法的語義。
如果按照HTTP方法的語義來暴露資源，那麼介面將會擁有安全性和冪等性的特性，例如GET和HEAD請求都是安全的， 無論請求多少次，都不會改變伺服器狀態。而GET、HEAD、PUT和DELETE請求都是冪等的，無論對資源操作多少次， 結果總是一樣的，後面的請求並不會產生比第一次更多的影響。
下面列出了GET，DELETE，PUT和POST的典型用法。
1.GET

• 安全且冪等
• 獲取表示
• 變更時獲取表示（快取）
• 200（OK） - 表示已在響應中發出
• 204（無內容） - 資源有空表示
• 301（Moved Permanently） - 資源的URI已被更新
• 303（See Other） - 其他（如，負載均衡）
• 304（not modified）- 資源未更改（快取）
• 400 （bad request）- 指代壞請求（如，引數錯誤）
• 404 （not found）- 資源不存在
• 406 （not acceptable）- 服務端不支援所需表示
• 500 （internal server error）- 通用錯誤響應
• 503 （Service Unavailable）- 服務端當前無法處理請求

2.POST

• 不安全且不冪等
• 使用服務端管理的（自動產生）的例項號建立資源
• 建立子資源
• 部分更新資源
• 如果沒有被修改，則不過更新資源（樂觀鎖）
• 200（OK）- 如果現有資源已被更改
• 201（created）- 如果新資源被建立
• 202（accepted）- 已接受處理請求但尚未完成（非同步處理）
• 301（Moved Permanently）- 資源的URI被更新
• 303（See Other）- 其他（如，負載均衡）
• 400（bad request）- 指代壞請求
• 404 （not found）- 資源不存在
• 406 （not acceptable）- 服務端不支援所需表示
• 409 （conflict）- 通用衝突
• 412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的衝突）
• 415 （unsupported media type）- 接受到的表示不受支援
• 500 （internal server error）- 通用錯誤響應
• 503 （Service Unavailable）- 服務當前無法處理請求

3.PUT

• 不安全但冪等
• 用客戶端管理的例項號建立一個資源
• 通過替換的方式更新資源
• 如果未被修改，則更新資源（樂觀鎖）
• 200 （OK）- 如果已存在資源被更改
• 201 （created）- 如果新資源被建立
• 301（Moved Permanently）- 資源的URI已更改
• 303 （See Other）- 其他（如，負載均衡）
• 400 （bad request）- 指代壞請求
• 404 （not found）- 資源不存在
• 406 （not acceptable）- 服務端不支援所需表示
• 409 （conflict）- 通用衝突
• 412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的衝突）
• 415 （unsupported media type）- 接受到的表示不受支援
• 500 （internal server error）- 通用錯誤響應
• 503 （Service Unavailable）- 服務當前無法處理請求

4.DELETE

• 不安全但冪等

• 刪除資源

• 200 （OK）- 資源已被刪除

• 301 （Moved Permanently）- 資源的URI已更改

• 303 （See Other）- 其他，如負載均衡

• 400 （bad request）- 指代壞請求

• 404 （not found）- 資源不存在

• 409 （conflict）- 通用衝突

• 500 （internal server error）- 通用錯誤響應

• 503 （Service Unavailable）- 服務端當前無法處理請求

  下面我們來看一些實踐中常見的問題:
  (1). POST和PUT用於建立資源時有什麼區別?
  POST和PUT在建立資源的區別在於，所建立的資源的名稱(URI)是否由客戶端決定。 例如為我的博文增加一個java的分類，生成的路徑就是分類名/categories/java，那麼就可以採用PUT方法。不過很多人直接把POST、GET、PUT、DELETE直接對應上CRUD，例如在一個典型的rails實現的RESTful應用中就是這麼做的。
  我認為，這是因為rails預設使用服務端生成的ID作為URI的緣故，而不少人就是通過rails實踐REST的，所以很容易造成這種誤解。
  (2). 客戶端不一定都支援這些HTTP方法吧?
  的確有這種情況，特別是一些比較古老的基於瀏覽器的客戶端，只能支援GET和POST兩種方法。
  在實踐上，客戶端和服務端都可能需要做一些妥協。例如rails框架就支援通過隱藏引數_method=DELETE來傳遞真實的請求方法， 而像Backbone這樣的客戶端MVC框架則允許傳遞_method傳輸和設定X-HTTP-Method-Override頭來規避這個問題。
  (3). 統一介面是否意味著不能擴充套件帶特殊語義的方法?
  統一介面並不阻止你擴充套件方法，只要方法對資源的操作有著具體的、可識別的語義即可，並能夠保持整個介面的統一性。
  像WebDAV就對HTTP方法進行了擴充套件，增加了LOCK、UPLOCK等方法。而github的API則支援使用PATCH方法來進行issue的更新，例如:
  PATCH /repos/:owner/:repo/issues/:number
  不過，需要注意的是，像PATCH這種不是HTTP標準方法的，服務端需要考慮客戶端是否能夠支援的問題。
  統一資源介面對URI有什麼指導意義?
  統一資源介面要求使用標準的HTTP方法對資源進行操作，所以URI只應該來表示資源的名稱，而不應該包括資源的操作。
  通俗來說，URI不應該使用動作來描述。例如，下面是一些不符合統一介面要求的URI:

  • GET /getUser/1
  • POST /createUser
  • PUT /updateUser/1
  • DELETE /deleteUser/1

  (3).如果GET請求增加計數器，這是否違反安全性?
  安全性不代表請求不產生副作用，例如像很多API開發平臺，都對請求流量做限制。像github，就會限制沒有認證的請求每小時只能請求60次。
  但客戶端不是為了追求副作用而發出這些GET或HEAD請求的，產生副作用是服務端"自作主張"的。
  另外，服務端在設計時，也不應該讓副作用太大，因為客戶端認為這些請求是不會產生副作用的。

  參考地址:https://www.runoob.com/w3cnote/restful-architecture.html

推薦文章

《前端程式設計師面試筆試寶典》P162，https://book.douban.com/subject/30324146/

理解RESTful架構，http://www.ruanyifeng.com/blog/2011/09/restful.html

RESTful 架構風格概述,https://blog.igevin.info/posts/restful-architecture-in-general/

前後端分離與restful api介紹，https://zhuanlan.zhihu.com/p/32901317