我有一個帶有一report_url列的資料庫表。一旦后端完成填充和存盤報告，它就會使用 S3 鏈接填充該列。如果報告尚未存盤，則列值默認為 NULL。我也有 Pyramid API，其中宣告了一個端點回傳帶有報告內容正文的回應。因此，每當用戶提出請求時，相應的控制器將被觸發以獲取報告鏈接并下載檔案并將其回傳給用戶。但是，如果報告尚未完成（report_url為 NULL），我需要以某種方式通知用戶。在這種情況下，前端應該收到 HTTP 狀態 400，但我還沒有弄清楚這是否最合適。或者也許 503 更適合這里？
uj5u.com熱心網友回復：
查看可用的http 狀態代碼。
您可能想要的是 404，特別是因為這一行：
在 API 中，這也可能意味著端點有效但資源本身不存在。：
詳細描述：
404 未找到
服務器找不到請求的資源。在瀏覽器中，這意味著無法識別 URL。在 API 中，這也可能意味著端點有效但資源本身不存在。服務器也可以發送此回應而不是 403 Forbidden 以向未經授權的客戶端隱藏資源的存在。此回應代碼可能是最廣為人知的，因為它在網路上頻繁出現。
如果服務器正在努力獲取報告，則 102 將獲得榮譽獎：
102 處理 (WebDAV)
此代碼表示服務器已收到并正在處理請求，但還沒有可用的回應。
它不是標準的一部分，它是一個擴展，WebDAV。
400 個狀態碼用于讓用戶知道他們所做的某些事情不起作用。當服務器發生某些事情時，使用 500 個狀態代碼。反正我是這么理解的。
這樣，如果這是 API/程式的“正常”執行，也許 200 狀態代碼就可以了。{"report_url": null}例如，如果它沒有準備好，只需定義要回傳的端點，否則{"report_url": "an actual url"}，否則在每種情況下都給出 200。接收方根據它是否為空來處理它。這種方法的優點是，現在用戶可以知道它絕對是一個正確的端點（而不是 url 拼寫錯誤，也會給出 404）。但是，您可以制作自己的 404 頁面，例如說“報告尚未準備好”或“報告不存在”。這種 200 方法的缺點是一些速度損失，因為您必須發送不必要的回應正文。
免責宣告：我根本不是 web/http 專家。
uj5u.com熱心網友回復：
正確的 HTTP 狀態代碼是202 - Accepted. 檔案說：
202（Accepted）狀態碼表示請求已被接受處理，但處理尚未完成。
..
與此回應一起發送的表示應該描述請求的當前狀態并指向（或嵌入）一個狀態監視器，該監視器可以為用戶提供對何時完成請求的估計。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/525836.html
標籤：http网络后端