支付平台的REST API交易

Question

以下是旨在為組織（顯示為第三方）開發支付平台的體系結構。 每個實體都有一組REST API。 暫時來說，我正在開發類似Paypal的產品。

我已經用垂直線（紅色，藍色）清楚地標記了邊界。 涉及三方。 付款門戶網站，銀行和第三者。

1. 客戶可以通過登錄到支付門戶來發起交易。 支付門戶將調用銀行的API。 請求流如圖所示。
2. 每個請求和響應都將通過ESB進行記錄。 如果交易成功，ESB將更新第三方數據庫並同時通知付款門戶。
3. 支付門戶將向ESB發起另一個API調用，以確保正確更新了第三方數據庫（未在圖片中顯示）。
4. 最后，付款門戶網站將向銀行發送確認，表明交易已完成整個周期（圖中未顯示）。 這是另一個API調用。

問題是，如果兩方之間存在網絡問題並且無法完成截斷周期，該怎么辦。 應該如何解決？

假設支付門戶網站發起請求后，支付門戶網站和第三者之間的網絡將丟失。 即使在銀行端成功完成交易，支付門戶也將無法獲得響應。 一旦網絡在線銀行，應該如何處理？

我在下面閱讀。

在REST中進行交易？

Answer 1

首先，您應該忘記同步處理事務。

在第一種情況下，您初始化交易，並以200 OK代碼返回交易數據及其狀態 。 在開始狀態可以是例如開始 。 然后，您反復發送GET請求以獲取所有交易數據，並在其狀態更改為例如Finished時顯示適當的信息。 在這種情況下，如果客戶端和服務器之間的連接斷開，則不會發生任何不良情況-所有數據都保留在服務器端，並且客戶端將充當觀察者。 總結起來，使用200 OK代碼以及交易狀態。

在第二種情況下，HTTP狀態代碼指示事務是否完成。 如果開始/提交事務，則響應包含事務數據，並將其標記為202 Accepted 。 沒有內部狀態字段。 然后，您應該重復查詢端點，直到200 OK或204 No Content返回（在正確答案的情況下）或4XX （ 5XX ），以防萬一。

這兩種方法僅在涉及指示事務是否完成這一事實時才不同：通過資源內部字段或HTTP狀態代碼。