要在未找到的子資源上返回的狀態代碼

Question

所以假設我有兩個資源，Wallet和User。 用戶和電子錢包具有一對一的關系。 在我的REST API中，我提供了一個選項，可以通過ID為用戶提供不同的Wallet。 因此，將用戶移動到其他錢包的典型HTTP PUT請求可能如下所示：

PUT /api/user/3 HTTP/1.1
Host: api.myuserandwalletwebsite.com

{
    "wallet_id": 15
}

這將更新用戶以使用id = 15的錢包。 但是，如果PUT請求包含在數據庫中找不到的wallet_id，該怎么辦？ 那么REST API應該返回什么？ 只是一個簡單的404？

在未找到的子資源上返回404對我來說感覺很奇怪，因為404會產生誤導：你可能認為404實際上是指未找到用戶。

Answer 1

404 (Not Found)絕對不是正確的響應代碼。 您需要的響應代碼是422 (Unprocessable Entity) 。

422（不可處理實體）狀態代碼表示服務器
了解請求實體的內容類型（因此a
415（不支持的媒體類型）狀態代碼不合適），和
請求實體的語法是正確的（因此是400（錯誤請求）
狀態代碼不合適）但無法處理包含的指令。
- RFC 4918

它是一個易於理解且定義明確的響應代碼，可以在IANA維護的超文本傳輸​​協議（HTTP）狀態代碼注冊表中找到 。

另外，根據規范 ，您沒有使用HTTP PUT。 PUT應以冪等方式更新資源的全部內容。 您應該使用PATCH或POST。

作為替代方案，您可以考慮加入資源，例如/ user-wallet端點。 根據您的API的具體情況，這可能有意義也可能沒有意義。

Answer 2

在我使用REST-API的應用程序中，我嘗試遵循此處描述的最佳實踐： http ： //www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api我知道很多來自GOOD軟件開發的程序員公司也關心這一點。 正如在未找到資源的情況下的最佳實踐中所描述的那樣簡單使用：

404 Not Found - When a non-existent resource is requested 

這是第一種情況 - 常見的最佳做法。

第二：最好的REST-API實踐背后的事情是你的應用程序邏輯：我認為你有一些基於你的app邏輯的選項：

404 Not Found - When a non-existent resource is requested because You requested non-existing wallet

405 Method Not Allowed - You cant put because wallet not found and it is required for update

422 Unprocessable Entity - Used for validation errors because we have validation in our app that check for incomming requests

所以具體狀態只是你的決定。 請記住，您選擇的選項將為您的邏輯應用程序的其余部分傳播，因此請保持一致並考慮REST-API，如專用於其他應用程序的GUI

Answer 3

就像你已經提到的那樣：我也不會使用404，因為這意味着無法找到用戶。 由於您想要更新您的用戶資源並且此更新由於無效數據（對無效電子錢包的引用）而失敗，我寧願使用400錯誤請求並向其他標題字段添加有意義的消息（例如，X-Message：帶有ID的電子錢包15找不到）。

HTTP 422不可處理的實體也是一個好主意，但RFC2616中沒有涉及。 如果這個“擴展”沒有問題，你可以選擇這個。

HTTP 405在這里不正確，因為這意味着通常不允許在用戶資源上使用PUT方法，並且在向資源觸發OPTIONS時不會包括PUT，而不是這種情況。