當請求需要先完成另一個請求時，我可以使用HTTP響應424嗎？

Question

例如，我有一個實體層次結構，並且由於某些問題，我收到創建父項請求之前創建子項的請求。

在這種情況下使用代碼424是否正確？

Answer 1

對此有絕對的意見空間。 RFC4918定義了HTTP狀態代碼424（重點煤礦）：

的424（失敗的依賴）狀態代碼意味着該方法不能對資源，因爲請求的動作依賴於另一個動作執行和操作失敗。例如，如果PROPPATCH方法中的命令失敗，那麼至少其餘命令也將失敗，並顯示424（失敗的依賴關係）。

在我看來，這不符合您的情況，因爲依賴操作尚未發生，而此狀態碼似乎表明依賴操作已收到但失敗。 409衝突的

朱利安Rechke的答案是在RFC2616定義爲

請求無法完成，因爲與資源的當前狀態的衝突。只有在預期用戶可能能夠解決衝突並重新提交請求的情況下，才允許使用此代碼。響應主體應該包含足夠的信息以供用戶識別衝突的來源。理想情況下，響應實體會爲用戶或用戶代理提供足夠的信息來解決問題;然而，這可能是不可能的，也不是必需的。

但是，如果接收此響應的客戶端能夠修復問題（在本例中爲創建父項），則只應使用此響應。如果不是這種情況，我可能推薦422無法處理的實體，再從RFC4918：

的422（無法處理的實體）的狀態代碼表示服務器理解請求實體的內容類型（因此一個415（不支持的媒體類型）狀態碼是不合適的），並且請求實體的語法是正確的（因此400（錯誤請求）狀態碼不合適），但是無法處理包含的指令。例如，如果XML請求體包含格式正確（即，語法正確）但語義錯誤的XML指令，則可能會出現此錯誤情況。

否則只是一個良好的老式400錯誤的請求，因爲它並沒有真正意義的創造並不在請求時存在，在該點父母的孩子。

Answer 2

恕我直言，你應該，問題是多麼知道這個狀態碼。我必須先看看維基百科。

但是我會說，即使客戶端默認情況下不處理此代碼，也很容易猜測這是客戶端錯誤。

如果可能的話，我會添加一個提示什麼叫失蹤。

Answer 3

424在WebDAV中定義;這不是問題，但WebDAV用於描述狀態碼409（衝突）的錯誤情況。這就是我會用的。