我發現 Http 207 可用于批量插入/洗掉/...等操作，我們可能會插入多個專案，從業務角度來看，部分成功是可以的。
我想知道如果我們有 API Post 呼叫一些外部服務，是否同樣適用？
示例業務場景：
我們有正在創建訂單的 HttpPost 端點。
HttpPost:
/api/order/
現在讓我們假設這個端點除了創建一個訂單外，還將呼叫外部服務來列印該訂單的標簽，另一個通過 REST 向外部第 3 方系統發送某種確認。
現在在這種情況下，我們假設創建 Order 是此操作成功的必要條件，但列印和外部 REST 呼叫都可能回傳錯誤訊息。這可能超出了我們的控制范圍。
現在從我讀到的關于如何回傳此資訊的選項將是：
- 帶有某種包含必要資訊的物件的 Http 200。例如：
{ "isSucess": true, "isFailure": true, "erorMesage": "string" } - 使端點更加 RESTful 并將其分成 3 個將被呼叫的操作，但在這種情況下，這不適用（至少從我的角度來看），因為所有這些東西從業務角度來看都是緊密耦合的，它們應該系結在一起
- 回傳 5xx 錯誤。502，因為并非所有操作都成功并且存在一些內部問題，但是如果一個失敗的操作是 502 和另一個 503 怎么辦
- 回傳 207 錯誤，并為每個操作提供正確的錯誤回應（訂單創建：200，列印：502，外部第 3 方：502）
現在我想知道哪個最合適？我有點傾向于 502 錯誤或 207，因為我認為它們提供了有關系統實際狀態的最多資訊。
uj5u.com熱心網友回復：
這是一個關于如何將 REST Web 服務用于嵌套分布式事務的設計問題。有很多合適的答案。這是我對此的看法，我在參考 REST 規范的同時解決了您的每個觀點。
- HTTP 代碼 207 不是一個好主意 - 此回傳代碼 (207) 是為支持 HTTP 上的 WebDAV ( https://en.wikipedia.org/wiki/WebDAV ) 擴展的系統指定的。WebDAV 是分布式的，但它是一個規范
允許用戶代理直接在 HTTP Web 服務器中協作創作內容
WebDAV 并不是專門為分布式事務構建的。可以處理回傳碼 207 的服務器需要在其中安裝 WebDAV 模塊。您甚至可能無法在多個 REST 庫中獲得此??回傳碼的支持。例如，此 API 檔案沒有代碼 207。https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Response.Status.html（這是一個邊緣案例，但它有幫助說明問題）。
- 如果請求部分滿足，我不喜歡使用 HTTP 50x。讓我們以服務器創建訂單但無法將其發布到第三方 REST 服務器（該服務器已關閉或網路錯誤）的情況為例。這是 50x 錯誤的規范https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html：
“以數字“5”開頭的回應狀態代碼表示服務器知道它已經出錯或無法執行請求的情況。”
服務器在這里沒有錯。它創建了物體。
- 我的建議是回傳 HTTP cod 202 on
POST /api/order/，回傳對訂單的參考并異步處理這些步驟。此請求涉及多個事務 - 列印標簽、更新第三方 REST 端點等。這些可以在“訂單”資源中更新。例如，POST /api/order/可以以這種格式回傳：
HTTP狀態202（接受）{“訂單”：{“id”：“1234567”}}
客戶端應使用 來檢查完整狀態GET /api/order/，這將回傳單個狀態：
{“id”：1234567，“label_printed”：“失敗”，“third_party_updated”：“成功”}
如果訂單的任何子交易失敗并且應該重新處理，則它是對現有訂單的更新，并呼叫PUT /api/order/，因為 PUT 方法是更新資源。服務器將接受 PUT 請求并根據需要重試事務。
以下是一些適合此問題的其他答案：
REST 中的事務？
跨 REST 微服務的事務？
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/430761.html