公司突然要求使用接口地址使用RESTful風格的接口命名規范，於是周末就對restful接口命名規范做了一個總結
REST是一個術語的縮寫，REpresentational State Transfer，中文直譯是“表征狀態轉移”。
REST是一套風格約定，RESTful是它的形容詞形式。比如一套實現了REST風格的接口，可以稱之為RESTful接口。
REST 描述了 HTTP 層里客戶端和服務器端的數據交互規則；客戶端通過向服務器端發送 HTTP（s）請求，接收服務器的響應，完成一次 HTTP 交互。這個交互過程中，REST 架構約定兩個重要方面就是HTTP請求的所采用方法，以及請求的鏈接。
因此，REST 規范可以簡單粗暴抽象成以下兩個規則：
- 請求 API 的 URL 表示用來定位資源；
- 請求的 METHOD 表示對這個資源進行的操作；
以下將以這兩個規則為基礎，描述如何構造一個符合 REST 規范的請求。
API的url
URL 用來定位資源，跟要進行的操作區分開，這就意味着URL不該有任何動詞。
1.1 下面示例中的 get、create、search 等動詞，都不應該出現在 REST 架構的后端接口路徑中。比如：
/api/getUser/api/createApp/api/searchResult/api/deleteAllUsers
1.2 當我們需要對單個用戶進行操作時，根據操作的方式不同可能需要下面的這些接口：
/api/getUser （用來獲取某個用戶的信息，還需要以參數方式傳入用戶 id 信息）/api/updateUser （用來更新用戶信息）/api/deleteUser （用來刪除單個用戶）/api/resetUser （重置用戶的信息）
1.3 可能在更新用戶不同信息時，提供不同的接口，比如：
/api/updateUserName/api/updateUserEmail/api/updateUser
1.4 總結：
以上三種情況的弊端在於：首先加上了動詞，肯定是使 URL 更長了；其次對一個資源實體進行不同的操作就是一個不同的 URL，造成 URL 過多難以管理。
其實當你回過頭看“URL”這個術語的定義時，更能理解這一點。URL 的意思是統一資源定位符，這個術語已經清晰的表明，一個 URL 應該用來定位資源，而不應該摻入對操作行為的描述。
在 REST 架構的鏈接應該是這個樣子：
一、請求 API 的 URL 表示用來定位資源
1、URL 中不應該出現任何表示操作的動詞，鏈接只用於對應資源；
2、URL 中應該單復數區分，推薦的實踐是永遠只用復數；比如GET /api/users表示獲取用戶的列表；如果獲取單個資源，傳入 ID，比如/api/users/123表示獲取單個用戶的信息；（個人覺得還是要區分一下單復數，/api/users表示獲取用戶的列表；/api/user/123表示獲取單個用戶的信息。這樣寫的好處是通過地址就能得知返回的是實體是一個對象，還是一個集合）
3、按照資源的邏輯層級，對 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 的成員）
二、請求的 METHOD 表示對這個資源進行的操作
GET （SELECT）：從服務器檢索特定資源，或資源列表。
POST （CREATE）：在服務器上創建一個新的資源。
PUT （UPDATE）：更新服務器上的資源，提供整個資源。
PATCH （UPDATE）：更新服務器上的資源，僅提供更改的屬性。
DELETE （DELETE）：從服務器刪除資源。
正確示例：
單資源( singular-resourceX )
url樣例：order/ (order即指那個單獨的資源X)
GET – 返回一個新的order
POST- 創建一個新的order，從post請求攜帶的內容獲取值。
單資源帶id(singular-resourceX/{id} )
URL樣例：order/1 ( order即指那個單獨的資源X )
GET – 返回id是1的order
DELETE – 刪除id是1的order
PUT – 更新id是1的order，order的值從請求的內容體中獲取。
復數資源(plural-resourceX/)
URL樣例:orders/
GET – 返回所有orders
復數資源查找(plural-resourceX/search)
URL樣例：orders/search?name=123
GET – 返回所有滿足查詢條件的order資源。(實例查詢，無關聯) – order名字等於123的。
復數資源查找(plural-resourceX/searchByXXX)
URL樣例：orders/searchByItems?name=ipad
GET – 將返回所有滿足自定義查詢的orders – 獲取所有與items名字是ipad相關聯的orders。
單數資源(singular-resourceX/{id}/pluralY)
URL樣例：order/1/items/ (這里order即為資源X，items是復數資源Y)
GET – 將返回所有與order id 是1關聯的items。
singular-resourceX/{id}/singular-resourceY/
URL樣例：order/1/item/
GET – 返回一個瞬時的新的與order id是1關聯的item實例。
POST – 創建一個與order id 是1關聯的item實例。Item的值從post請求體中獲取。
singular-resourceX/{id}/singular-resourceY/{id}/singular-resourceZ/
URL樣例：order/1/item/2/package/
GET – 返回一個瞬時的新的與item2和order1關聯的package實例。
POST – 創建一個新的與item 2和order1關聯的package實例，package的值從post請求體中獲得。
以上規范是以查詢為主，下面重點說一下patch
patch主要用來更改部分字段，比如重命名，或者更改實體的狀態。這個時候兩個方法都要寫，，不能都寫成Patch /order/{id},這樣區分不出來。這個時候可以這樣做
/order/{id}/name (用來重命名)
/order/{id}/status(用來更改用戶狀態)
這樣就可以通過url和 method的兩種方式完美的區分開了兩個方法。
此處特殊說明一下，有的博客中使用/order/name/{id}這樣的命名規范，將id放在字段的后面，我不確定那種正確，但是根據查詢的相關規則，我選擇id還是直接跟在order后面合適。
上面的規則可以在繼續遞歸下去，並且復數資源后面永遠不會再跟隨負數資源。
總結幾個關鍵點，來更清晰的表述規則。
在使用復數資源的時候，返回的是最后一個復數資源使用的實例。
在使用單個資源的時候，返回的是最后一個但是資源使用的實例。
查詢的時候，返回的是最后一個復數實體使用的實例(們)。
其他規范
一些其他規范：
規則1：URI結尾不應包含（/）
規則2：正斜杠分隔符（/）必須用來指示層級關系
規則3：應使用連字符（ - ）來提高URI的可讀性
規則4：不得在URI中使用下划線（_）
規則5：URI路徑中全都使用小寫字母
參考博客
https://blog.csdn.net/qq_35075909/article/details/91522242
https://www.cnblogs.com/alsf/p/9362264.html