REST URL命名約定/ items / {id} vs / items？id = {id}

Question

我理解在MVC模式和REST服務中，通常使用像/items/{id}這樣的URI，但在URI中使用查詢參數有什么壞處？

GET /items/{id} vs GET /items?id={id}

此外，假設一個實體有'referenceId'字段指向一些相關（比如父）實體，我需要創建REST服務來獲取父實體的所有項目，哪種方式更好：

GET(POST) /items/parent/{parentId} 

要么

GET(POST) /items?parent={parentId}

將會感謝有助於解決構建REST服務URL的主觀問題的見解。

Answer 1

我會使用以下方案。

/items/id

這唯一地解決了id為id的項的資源。 我們沒有使用參數作為唯一地尋址此資源的參數（與其他選項的情況一樣）。 就像miguelcobain所說的那樣。

/parent/id/items

這里的id是一個id，用於唯一地尋址父資源以及我們收集/檢索它引用的項的資源。 根據你在問題中所說的，似乎父引用了多個項目，比如容器或集合。

我使用的慣例是縮小從左到右的范圍。 因此，如果項目可以是active或非inactive 。 因此，項目具有active或非inactive的屬性或屬性。 縮小這個我得到以下方案：

/items/active
/parent/id/active

Answer 2

對於你的第一個問題：

/items/{id}應檢索具有指定標識的單個資源，如果不存在，則檢索404 。

/items/?id={id}應檢索一個數組（即使數組中只有一個），因為您正在查詢該集合。

對於你的第二個問題：

我同意@ miguelcobain的評估 - 如果項目是特定的資源/實體，只需使用適當的資源路徑來檢索它。

為了使消費者更容易，請使用rel="parent"創建一個鏈接頭和/或在子資源中包含uri。 有關鏈接標頭的示例，請參閱GitHub的分頁API 。

Answer 3

當然，REST原則並不關心URL的美學細節。 它只是強加了每個資源都應該是唯一可尋址的。

此外，使用查詢參數唯一地尋址“種類”的東西違反了“參數”的語義，不是嗎？ 參數應該是可選的，附加的和參數化的。 例如，對項目集合的詳細搜索。

你寫的內容在某些情況下可能有意義。 這取決於。

在您的示例中， 項目是否真的是資源 ？ 如果沒有，你可以做GET(POST) /parents/{parentId} 。

如果parent是一個布爾值，並且你想搜索父等於true的項，那么使用這些參數是有意義的。 但是，由於您明確表示您希望父級具有特定ID，因此我認為父級是資源本身，我將使用您的選項1唯一地​​尋址該資源。

我希望我清楚自己。

Answer 4

在我看來，沒有規則可循。

items/{id} - 此約定適用於給定id的GET項。 如果用戶未提供id，則返回404狀態代碼。

items/id={id}&name={name} - 此類約定適用於按給定條件搜索多個項目。 如果沒有找到任何項目，則不是 404情況，您只需說“我成功找不到符合您搜索條件的內容”