RESTful 介面實現
REST 簡介
REST 是一個術語的縮寫，REpresentational State Transfer，中文直譯「表徵狀態轉移」，這是個很拗口的詞。我的建議是先不要強行理解，直接看怎麼做，等對實施細節有一些瞭解後，再來看名字會有更深刻的理解。REST 是一套風格約定，RESTful 是它的形容詞形式；比如一套實現了 REST 風格的介面，可以稱之為 RESTful 介面。
REST 對請求的約定
REST 用來規範應用如何在 HTTP 層與 API 提供方進行資料互動；在現階段，你應該已經很熟悉 GET 和 POST 請求；甚至有可能因為受限於後端框架限制等原因，你的整個應用全都是用這兩種 HTTP 方法來完成的。這樣無疑浪費了 HTTP 協議的潛力，而 REST 則充分利用了 HTTP 規範中的方法，達到介面描述的語義化。
REST 描述了 HTTP 層裡客戶端和伺服器端的資料互動規則；客戶端通過向伺服器端傳送 HTTP（s）請求，接收伺服器的響應，完成一次 HTTP 互動。這個互動過程中，REST 架構約定兩個重要方面就是 HTTP 請求的所採用方法，以及請求的連結。
在請求層面，REST 規範可以簡單粗暴抽象成以下兩個規則：
1. 請求 API 的 URL 表示用來定位資源；
2. 請求的 METHOD 表示對這個資源進行的操作；
以下將以這兩個規則為基礎，描述如何構造一個符合 REST 規範的請求。
一、API 的 URL
URL 用來定位資源，跟要進行的操作區分開，這就意味這 URL 不該有任何動詞；
下面示例中的 get、create、search 等動詞，都不應該出現在 REST 架構的後端介面路徑中。在以前，這些介面中的動名詞通常對應後臺的某個函式。比如：
/api/getUser /api/createApp /api/searchResult /api/deleteAllUsers
當我們需要對單個使用者進行操作時，根據操作的方式不同可能需要下面的這些介面：
/api/getUser （用來獲取某個使用者的資訊，還需要以引數方式傳入使用者 id 資訊） /api/updateUser （用來更新使用者資訊） /api/deleteUser （用來刪除單個使用者） /api/resetUser （重置使用者的資訊）
更有甚者，可能在更新使用者不同資訊時，提供不同的介面，比如：
/api/updateUserName /api/updateUserEmail /api/updateUser
這樣的弊端在於：首先加上了動詞，肯定是使 URL 更長了；其次對一個資源實體進行不同的操作就是一個不同的 URL，造成 URL 過多難以管理。
其實當你回過頭看「URL」 這個術語的定義時，更能理解這一點。URL 的意思是統一資源定位符，這個術語已經清晰的表明，一個 URL 應該用來定位資源，而不應該摻入對操作行為的描述。
在 REST 架構的連結應該是這個樣子：
- URL 中不應該出現任何表示操作的動詞，連結只用於對應資源；
- URL 中應該單複數區分，推薦的實踐是永遠只用複數；比如 GET /api/users 表示獲取使用者的列表；如果獲取單個資源，傳入 ID，比如 /api/users/123 表示獲取單個使用者的資訊；
- 按照資源的邏輯層級，對 URL 進行巢狀，比如一個使用者屬於某個團隊，而這個團隊也是眾多團隊之一；那麼獲取這個使用者的介面可能是這樣：
GET /api/teams/123/members/234 表示獲取 id 為 123 的小組下，id 為234 的成員資訊
按照類似的規則，可以寫出如下的介面
/api/teams （對應團隊列表） /api/teams/123 （對應 ID 為 123 的團隊） /api/teams/123/members （對應 ID 為 123 的團隊下的成員列表） /api/teams/123/members/456 （對應 ID 為 123 的團隊下 ID 未 456 的成員）
二、API 請求的方法
在很多系統中，幾乎只用 GET 和 POST 方法來完成了所有的介面操作；這個行為類似於全用 DIV 來佈局。實際上，我們不只有GET 和 POST 可用，在 REST 架構中，有以下幾個重要的請求方法：GET，POST，PUT，PATCH，DELETE。這幾個方法都可以與對資料的 CRUD 操作對應起來。
【Read】 資源的讀取，用 GET 請求；比如：
GET /api/users （ 表示讀取使用者列表）
GET 應當實現為一個安全方法。用於獲取資料而不應該產生副作用。
【Created】資源的建立，用 POST 方法；
POST 是一個非冪等的方法，多次呼叫會造成不同效果；
冪等（Idempotent）：如果對伺服器資源的多次請求與一次請求造成的副作用是一樣的的話，那這個請求方法可以被認為是冪等。
比如下面的請求會在伺服器上建立一個 name 屬性為 'John Snow' 的使用者；多次請求就會建立多個這樣的使用者。
POST /api/users { "name": "John Snow" }
【Update】資源的更新，用於更新的 HTTP 方法有兩個，PUT 和 PATCH。
他們都應當被實現為冪等方法，即多次同樣的更新請求應當對伺服器產生同樣的副作用。
PUT 和 PATCH 有各自不同的使用場景：
PUT 用於更新資源的全部資訊，在請求的 body 中需要傳入修改後的全部資源主體；
而 PATCH 用於區域性更新，在 body 中只需要傳入需要改動的資源欄位。
設想伺服器中有以下使用者資源 /api/users/123
{ "id": 123, "name": "Original", "age": 20 }
當我們往後臺傳送更新請求時，PATCH 和 PUT 造成的效果是不一樣。
PUT /api/users/123 { "name": "PUT Update" }
上述 PUT 請求操作後的內容是：
{ "id": 123, "name": "PUT Update" }
可以觀察到，資源原有的 age 欄位被清除掉了。
而如果改用 PATCH 的話，
PATCH /api/users/123 { "name": "PATCH Update" }
更新後的內容是：
{ "id": 123, "name": "PATCH Update", "age": 20 }
請求中指定的 name 屬性被更新了，而原有的 age 屬性則保持不變。
PATCH 的作用在於如果一個資源有很多欄位，在進行區域性更新時，只需要傳入需要修改的欄位即可。否則在用 PUT 的情況下，你不得不將整個資源模型全都發送回伺服器，造成網路資源的極大浪費。
【Delete】資源的刪除，相應的請求 HTTP 方法就是 DELETE。這個也應當被實現為一個冪等的方法。如:
DELETE /api/users/123
用於刪除伺服器上 ID 為 123 的資源，多次請求產生副作用都是，是伺服器上 ID 為 123 的資源不存在。
三、分頁、過濾
REST 風格的介面地址，表示的可能是單個資源，也可能是資源的集合；當我們需要訪問資源集合時，設計良好的介面應當接受引數，允許只返回滿足某些特定條件的資源列表。
比如支援以 offset 和 limit 引數來進行分頁；
GET /api/users?offset=0&limit=20
支援提供關鍵詞進行搜尋，以及排序
GET /api/users?keyword=john&sort=age
支援根據欄位進行過濾
GET /api/users?gender=male
設計合適的 API URL，以及選擇合適的請求方法，可以語義化的描述一個 HTTP 請求的操作。
當我們都熟悉且遵循這樣的規範後，基本可以看到一個 REST 風格的介面就知道如何使用這個介面進行 CRUD 操作了。比如下面這面這個介面就表示搜尋 ID 為 123 的圖書館的書，並且書的資訊裡包含關鍵字「game」，返回前十條滿足條件的結果。
GET /api/libraries/123/books?keyword=game&sort=price&limit=10&offset=0
同樣，下面這個請求的意思也就很明顯了吧。
PATCH /api/companies/123/employees/234 { "salary": 2300 }