在設(shè)計 RESTful API 時，有幾個關(guān)鍵要點需要特別注意，因為這些要點如果處理不好，容易導(dǎo)致錯誤或降低 API 的可用性和維護性。

01 領(lǐng)域模型

在設(shè)計 RESTful API 的路徑結(jié)構(gòu)時，可以參考領(lǐng)域模型。在領(lǐng)域驅(qū)動設(shè)計思想中，領(lǐng)域模型構(gòu)成了軟件的邏輯結(jié)構(gòu)。

這樣設(shè)計有幾個好處：

• 領(lǐng)域模型往往都是名詞，和 API Path 保持一致。
• 領(lǐng)域模型往往為樹形結(jié)構(gòu)，可以很好地轉(zhuǎn)換為 API Path。
• 團隊成員能保持風(fēng)格統(tǒng)一的 API 設(shè)計。

圖片

02 選擇合適的 HTTP Methods

HTTP 協(xié)議提供了非常多種 Methods，但對于應(yīng)用系統(tǒng)而言，使用過多的 HTTP Methods 會給開發(fā)者帶來困擾。

因此，定義基本的幾個 HTTP Methods 可以簡化 API 設(shè)計，這取決于團隊風(fēng)格。

例如，PATCH 在很多時候會給團隊造成困擾，開發(fā)者往往不能清晰地辨別在何種場景下使用 PATCH 還是 PUT，因此根據(jù)團隊約定，可以統(tǒng)一使用 PUT。

03 冪等

提前進行冪等性設(shè)計可以提高 API 的健壯性。

• GET 類型的 API 具有天然的冪等性，所以避免在 GET 類型的 API 中實現(xiàn)數(shù)據(jù)的變更操作。
• PUT、DELETE 類型的 API 應(yīng)該特別注意實現(xiàn)上盡量冪等，這樣在 API 調(diào)用出錯重試時不會帶來意外的結(jié)果。
• POST 為新增操作，理論上來說不應(yīng)該實現(xiàn)為冪等，但在必要時可以通過輸入?yún)?shù)設(shè)計為冪等。

04 選擇合適的HTTP 狀態(tài)碼

和 HTTP Methods 類似，HTTP 狀態(tài)碼也非常多。根據(jù)經(jīng)驗，開發(fā)者在選擇使用哪一個狀態(tài)碼時，非常容易犯錯，且難以在團隊內(nèi)達成統(tǒng)一。

比較好的方法是，定義有限的 HTTP 狀態(tài)碼來使用即可，來簡化應(yīng)用開發(fā)的難度。例如，當(dāng)發(fā)生校驗錯誤時，統(tǒng)一返回 400，當(dāng)發(fā)生業(yè)務(wù)錯誤時，統(tǒng)一返回 419。

05 版本控制

提前為 API 設(shè)計版本號可以簡化后期的改造和升級工作。

API 版本信息通常有三種方式：

• 使用 Path 前綴，將版本號放到 API Path 的前面。
• 使用 Query 參數(shù)。
• 使用 Header 參數(shù)。

比較推薦的方法是使用 Path 前綴，對于提供者和消費者來說都非常容易理解，且不會侵入其它的業(yè)務(wù)參數(shù)。

06 語義化 API 路徑

讓 API Path 保持語義化可以增加 API 的辨識度，讓消費者更容易在文檔中找到合適的 API。

提高語義化的方法有：

• 區(qū)分名詞的單復(fù)數(shù)，避免錯誤單詞拼寫。
• 盡量使用資源名稱代替動作。
• 如果實在無法避免動詞，也盡可能將動詞放到路徑末尾，并使用 POST method。

07 批量處理

提前為批量 API 設(shè)定一套規(guī)則，讓批量 API 更加語義化。我們可以進行約定：

• 使用 batch/bulk 作為關(guān)鍵字，放置到路徑末尾。
• 當(dāng)需要批量查詢數(shù)據(jù)時，通過 Query 參數(shù)代替 Path 參數(shù)。

08 查詢語言設(shè)計

提前設(shè)計一套具有拓展性的查詢規(guī)則，可以讓 API 更加靈活。

• 分頁：預(yù)留分頁參數(shù)關(guān)鍵字。
• 排序：預(yù)留排序參數(shù)關(guān)鍵字，以及排序的方向。例如通過 sort=name:asc,age:desc 表達根據(jù)名稱正序，年齡倒序排序。
• 過濾：設(shè)置靈活的過濾條件語法，可以定義一些指令來實現(xiàn)更加靈活的過濾方式。例如，

GET /v1/users?age=gt:20,lt:50&name=match:lisa&gender=eq:male

其中，gt 代表大于，lt 代表小于，match 代表模糊搜索，eq 代表完全匹配。