在 RESTful API 中處理 boolean 端點

Question

盡管 SO 中有多個關於 RESTful API 中的命名約定的問題，但我找不到任何關於如何處理 boolean 端點（返回 Z84E2C64F38F78BA3EA5C905AB5A2DA27 值的端點）的參考。

考慮具有資源/products和/orders的 API。
一個訂單可能會引用多個產品，因此無法在不與相關訂單混淆的情況下刪除一個產品。
在訂單引用的產品中調用DELETE /products/:id將返回409 Conflict 。

到目前為止，一切都非常簡單，但是如果客戶想確認這個產品是否可以刪除呢？

boolean 端點將返回真或假（或以某種方式包含此值的 JSON 結構）。
GET /products/:id/can-be-deleted

這里的問題是can-be-deleted不是（子）資源，它是檢查某些東西的動作......
我覺得如果 RESTful API 應該使用名詞並且不應該在端點中有動詞，那么它也不應該有形容詞（ /deletable ， /completed ）或謂詞（ /can-be-deleted ， /is-ready ）。

如果是這樣，這方面的慣例是什么？
這些信息應該有它自己的端點嗎？
如果是這樣，這個端點應該如何命名？
如果不是，此信息是否應該是另一個端點的一部分（例如GET /products/:id返回此信息）？

Answer 1

在訂單引用的產品中調用 DELETE /products/:id 將返回 409 沖突。

到目前為止，一切都非常簡單，但是如果客戶想確認這個產品是否可以刪除呢？

如果您嘗試驗證是否可以刪除資源：

OPTIONS /products/1

200 OK
Allow: GET, DELETE
Content-Length: 0

請注意，DELETE 的語義屬於通過網絡傳輸文檔。

相對較少的資源允許使用 DELETE 方法——它的主要用途是遠程創作環境，用戶對其效果有一定的指導。 -- RFC-7231

---

在 web 上，如何知道是否可以提交表單？ 答案很簡單：表格已提供給您。 如果您沒有獲得表格（或鏈接），則不允許您使用它。 這就是統一的接口約束：“超媒體作為應用程序 state 的引擎。”

我們從表示中添加或刪除元素以指示您可以通過應用程序采用的路徑。 作為客戶，您檢查以確保您的陳述仍然是新鮮的； 如果是這樣，那么您可以選擇發送請求。

---

這里的問題是 can-be-deleted 不是（子）資源，它是檢查某些東西的動作......

一點也不：這是關於某事的報告。

“檢查某事的操作”的一個經典示例是服務“健康檢查”，我們使用這種方法來檢測需要從負載均衡器中刪除主機。

任何可以命名的信息都可以是一種資源—— 菲爾丁，2000

機器不關心我們為資源使用什么標識符； 因此，如果我們願意，我們可以利用這種自由讓人們的事情變得更輕松。 通常，清楚地了解資源 model 可以很容易地識別候選標識符； 因此，當您在發現“足夠好”的標識符時遇到問題時，我建議您更多地考慮 model。

Answer 2

建議：

• 專注於“眼前的問題”。 在這種情況下，為您的“刪除項目”操作提供 API（或 API）。
• 一種選擇是擁有多個 API：例如，“查詢項目狀態”和“刪除指定項目”。
• 另一種選擇是擁有一個 API（“刪除指定項目”）並在無法刪除時報告有意義的狀態代碼/錯誤消息。
• 沒有“一刀切”的答案。 這是一個判斷電話。
• 您選擇的 API 名稱 - 以及您選擇的 HTTP 動詞 - 將成為您決定的一部分。
• 是否將您碰巧為“刪除”動作做出的選擇外推到其他不同的動作也是一個判斷電話。

'希望有幫助...

PS：

如果您還沒有這樣做，我鼓勵您（重新）閱讀 Roy Fielding 的原始論文：

代表性 State 傳輸 (REST)