本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

非同步通訊

相反地，在非同步通訊中，用戶端會向服務發出請求，但不會立即收到回應。在此情況下，用戶端通常只會收到接受請求的確認。

非同步通訊的優點包括：

缺點包括複雜性。例如：

非同步通訊的方法包括火災和忘記、宣告檢查、回呼和雙向通訊。

Fire 和 忘記

在觸發和忘記模式中，用戶端會向伺服器發出請求，並同步接收確認，指出伺服器已收到訊息並進行處理。不過，實際處理尚未發生，而且用戶端無法查看何時或如何完成。下圖說明此模式。

在此情況下，在物件持久保留之前，服務不應傳送確認。此持久性可以實作為資料庫寫入操作或將項目放入佇列中。

其他考量：

宣告檢查

如果用戶端需要服務呼叫的結果，您可以建置服務，在收到請求時發出宣告檢查。下圖說明此模式。宣告檢查會實作為服務在其確認中傳回的識別符。用戶端稍後可以使用此識別符來檢查請求的狀態，並在請求完成時擷取結果。

用戶端必須實作機制來輪詢結果。這可以是自動化 （例如，每 n 分鐘可以執行一次檢查） 或手動實作，其中執行檢查是為了回應另一個事件或使用者動作。實作宣告檢查模式的服務應明確宣告檢查有效的時間長度。

最佳實務：

回電

在回呼模式中，用戶端會向服務發出請求，並提供服務在處理完成時聯絡的位置。用戶端不會等待結果，而處理會繼續。服務負責在處理完成時聯絡 據點並提供結果。回應的常見位置類型為 REST APIs 或佇列。下圖說明回呼模式。

實作：

雙向通訊

若要實作雙向通訊，您必須在用戶端和服務之間建立具狀態的連線，這可讓用戶端和服務傳送和處理訊息。這會在下列圖表中進行說明。雖然通訊是非同步的，但服務必須能夠支援每個用戶端的開放連線。

實作考量：