REST URI約定-建立資源時的單數或複數名稱

我是REST的新手，我注意到在某些RESTful服務中，它們使用不一樣的資源URI進行更新/獲取/刪除和建立。 如

• 建立-使用POST方法，使用/資源 （觀察複數），使用/資源有些地方（單數）
• 更新-使用/ resource / 123和PUT方法
• 獲取-將/ resource / 123與GET方法一塊兒使用

我對此URI命名約定有點困惑。 咱們應該使用複數仍是單數來建立資源？ 決定的標準是什麼？

---

#1樓

儘管最廣泛的實踐是使用複數的RESTful api，例如/api/resources/123 ，但在一種特殊狀況下，我發現使用單數名稱比複數名稱更合適/更具表達性。 一對一的關係就是這種狀況。 特別是若是目標項目是值對象（在域驅動設計範式中）。

讓咱們假設每一個資源都有一對一的accessLog ，能夠將其建模爲值對象，即不是實體，所以沒有ID。 它能夠表示爲/api/resources/123/accessLog 。 經常使用動詞（POST，PUT，DELETE和GET）會適當地表達意圖，而且也代表這種關係確實是一對一的。

---

#2樓

爲何不遵循一般接受單數形式的數據庫表名稱的流行趨勢？ 到那裏，作完了-讓咱們重複使用。

表命名難題：單數與複數名稱

---

#3樓

對我來講，最好有一個能夠直接映射到代碼的模式（易於自動化），這主要是由於代碼將是兩端。

GET  /orders          <---> orders 
POST /orders          <---> orders.push(data)
GET  /orders/1        <---> orders[1]
PUT  /orders/1        <---> orders[1] = data
GET  /orders/1/lines  <---> orders[1].lines
POST /orders/1/lines  <---> orders[1].lines.push(data)

---

#4樓

從API使用者的角度來看，端點應該是可預測的

理想地...

1. GET /resources應該返回資源列表。
2. GET /resource應返回400級狀態代碼。
3. GET /resources/id/{resourceId}應該返回帶有一個資源的集合。
4. GET /resource/id/{resourceId}應該返回一個資源對象。
5. POST /resources應該批量建立資源。
6. POST /resource應該建立一個資源。
7. PUT /resource應該更新資源對象。
8. PATCH /resource應該僅經過發佈更改的屬性來更新資源。
9. PATCH /resources應該批量更新資源，僅發佈更改的屬性。
10. DELETE /resources應該刪除全部資源； 只是在開玩笑：400狀態碼
11. DELETE /resource/id/{resourceId}

這種方法最靈活，功能最豐富，但開發時間也最長。 所以，若是您很着急（在軟件開發中一般如此），只需命名端點resource或複數形式的resources 。 我更喜歡單數形式，由於它可讓您選擇以編程方式進行內省和評估，由於並不是全部複數形式都以「 s」結尾。

綜上所述，不管出於何種緣由，開發人員最經常使用的選擇是使用複數形式。 這最終是我選擇的路線，若是您查看諸如github和twitter類的流行api，這就是它們的做用。

決定的一些標準多是：

1. 個人時間限制是什麼？
2. 我將容許個人消費者執行哪些操做？
3. 請求和結果有效載荷是什麼樣的？
4. 我是否但願可以使用反射並解析代碼中的URI？

所以，取決於您。 不管您作什麼，都要保持一致。

---

#5樓

個人兩分錢：花費時間從複數變爲單數或反之亦然的方法是浪費CPU週期。 我多是高中生，可是在個人時代，事物被稱爲相同。 我如何查找有關人的方法？ 沒有規律的表達不會覆蓋人和人，而不會產生不良反作用。

英文複數能夠是很是任意的，它們沒必要要地妨礙了代碼。 遵照一個命名約定。 計算機語言應該是數學上的清晰度，而不是模仿天然語言。