如果客戶端嘗試上傳新文件而服務器仍在處理前一個文件，我應該返回哪個 HTTP 狀態？

Question

我的應用程序有一個允許用戶上傳文件的按鈕。 上傳文件非常快，我們非常快地向客戶端發送響應，但是服務需要一段時間來處理它。

只有當前一個文件已經處理完畢時，用戶才能上傳一個新文件。 因此，如果用戶在服務器仍在處理文件時嘗試上傳文件，我們應該向客戶端返回錯誤。

我的問題是我應該使用哪種 HTTP 響應狀態？ 我檢查了所有選項，這些是我認為更接近我的情況的選項：

409 Conflict - 表示由於資源當前狀態存在沖突而無法處理請求，例如多個同時更新之間的編輯沖突。
425 Too Early (RFC 8470) - 表示服務器不願意冒險處理可能被重放的請求。
428 Precondition Required (RFC 6585) - 源服務器要求請求是有條件的。 旨在防止“丟失更新”問題，其中客戶端獲取資源的狀態，修改它，並將其放回服務器，同時第三方修改了服務器上的狀態，導致沖突。 [58]

你認為哪一個最適合這種情況？ 或者其中任何一個，我應該使用另一個嗎？

Answer 1

你認為哪一個最適合這種情況？

429 狀態碼表示用戶在給定時間內發送了太多請求（“速率限制”）。

響應表示應該包含解釋條件的詳細信息，並且可以包含一個 Retry-After 標頭，指示在發出新請求之前要等待多長時間。

429 Too Many Requests
Retry-After: 60
Content-Type: text/plain

Why don't you wait a minute?

為什么我不提倡您推薦的任何代碼：

425 太早了； 我會避免這個，因為它似乎特定於早期數據的上下文。

428 需要先決條件； 這里的核心問題是如何與通用客戶端進行通信，請求中應包含哪個先決條件。 此外，從語義上講，它有點偏離。

409 沖突； 在實踐中，您也許可以使這一項工作。 從語義上講，困難在於客戶端確實沒有辦法解決沖突（例如：重新加載頁面以獲取服務器資源副本的新副本）。

需要認識到的重要一點是，HTTP 狀態代碼只是對人類來說是偶然的。 狀態碼是網絡文檔傳輸域的元數據； 目標受眾是通用 HTTP 組件（瀏覽器、蜘蛛、緩存、代理等）。

因此，要使用的“最佳”代碼將是告訴通用組件正確事情的代碼。 專業化發生在響應正文中，我們使用有效負載來傳達細粒度的細節。

Answer 2

您如何接收請求並將其放入隊列中。 為您的隊列創建一個消費者，以便在前一個完成之前無法處理任何請求。 這樣，無論當前狀態如何，您都可以只接受來自客戶的請求，並且只返回一個標准的確認響應 - 200 或您在成功時發送的任何響應。