使用無效FK發布資源后的REST API錯誤代碼

Question

我正在設計一個REST API，它的Banner資源與另外兩個資源有關： Placeholder和Page 。

盡管與Placeholder的關系可以為null ，但Banner必須與Page關聯。 業務規則定義頁面始終獨立創建。 然后，對於新的Banner資源，頁面始終存在，並且頁面ID可以作為參數傳遞。 Placeholder ，盡管它可以為null 。

因此，我決定還可以如下獨立創建Banner資源（而不是嵌套資源）：

POST https://api.example.com/banners
{
  "name": "banner's name",
  "page": "PAGE_ID",
  "placeholder": "PLACEHOLDER_ID",

  ... other parameters
}

如果提供的page或placeholder不存在，API應該返回什么錯誤代碼？

我正在返回HTTP 404，但感覺很奇怪。 我考慮過409，但這看起來並不像是沖突。

PD：如果我使用嵌套URL作為POST /pages/<page_id>/banners ，則404對於不存在的page是有意義的，但對於placeholder仍然存在相同的問題。

Answer 1

假設您要使用POST /banners創建POST /banners資源，並且該POST /banners資源具有

• 必需的page屬性，該值必須是現有的PAGE_ID
• 可選的placeholder屬性，其值必須是現有的PLACEHOLDER_ID
• 我假設還必須控制 名稱和其他屬性

在帖子/橫幅上返回404不是一個好主意

使用者可以提供從無到全部無效的屬性。 按照您的想法，將得到類似的結果：

• 如果只有page無效，您將返回404
• 如果僅占位placeholder無效，您將返回404
• 如果page和placeholder均無效，則必須返回404，指示這兩個值均無效
• 如果其他屬性無效，則可能會返回400 Bad Request。
• 如果page和/或placeholder以及其他一些屬性無效，則返回哪個狀態？ 404或400？

這有點復雜且不一致，因此對於API的使用者而言確實不可用。

400錯誤的請求是帖子/橫幅的更好解決方案

處理此用例的最佳方法是將所提供資源中的所有可能錯誤都視為基本的Client Error ，因此使用400 Bad Request狀態。 響應的正文將包含對每個無效屬性的每個錯誤的描述。

但是使用POST / pages / page_id / placeholders / placeholder_id / banners有一個更清潔的解決方案

POST /pages/<page_id>/banners幾乎是一個好主意，您只需要進一步推動它即可。

似乎banner進入page的placeholder 。 如果屬實，則可以執行POST /pages/<page_id>/placeholders/<placeholder_id>/banners創建橫幅。

• 如果page_id無效，則返回404（指示“找不到頁面”）
• 如果page_id有效，但placeholder_id無效，則返回404（指示“未找到placeholder_id ”）
• 如果page_id和placeholder_id有效，但page_id屬性無效，則返回400錯誤請求（指示哪些值無效）