具外部程序的復原介面

發行項
06/19/2024

在本文中，我們將為您提供指導方針，說明如何在使用者旅程圖中規劃及實作 RESTful API，並讓您的應用程式對於 API 失敗更有復原能力。

此圖顯示具有外部程序元件的介面

確定 API 的位置正確

身分識別體驗架構 (IEF) 原則可讓您使用 RESTful API 技術設定檔來呼叫外部系統。外部系統不受 IEF 執行階段環境的控制，而且是潛在的失敗點。

如何使用 API 管理外部系統

呼叫介面以存取某些資料時，請檢查資料是否要驅動驗證決策。評估此資訊是否對應用程式的核心功能而言是不可或缺的。例如，電子商務與次要功能 (例如系統管理) 的比較。如果驗證不需要此資訊，而且只在次要案例中需要，則請考慮將呼叫移至應用程式邏輯。
如果驗證所需的資料相對靜態且小型，而且沒有其他商務理由要從目錄中外部化，則請考慮將其放在目錄中。
盡可能從預先驗證的路徑移除 API 呼叫。如果您無法這樣做，則必須針對阻斷服務 (DoS) 和分散式阻斷服務 (DDoS) 攻擊，在您的 API 前面放置嚴格保護。攻擊者可以載入登入頁面，並嘗試使用 DoS 攻擊對您的 API 進行洪水攻擊且停用您的應用程式。例如，在登入中使用 CAPTCHA，註冊流程可以提供協助。
使用內建註冊使用者流程的 API 連接器，在註冊期間與識別提供者同盟之後，或是在建立使用者之前，盡可能與 Web API 整合。由於使用者流程已經過廣泛的測試，因此您可能不需要執行使用者流程層級的功能、效能或規模測試。您仍然需要測試應用程式的功能、效能和規模。
Azure AD B2C RESTful API 技術設定檔不會提供任何快取行為。相反地，RESTful API 設定檔會實作重試邏輯和內建至原則的逾時。
對於需要寫入資料的 API，請將工作排入佇列，讓背景工作角色執行這類工作。您可以使用 Azure 佇列之類的服務。此練習會讓 API 有效率地傳回，並提高原則執行效能。

API 錯誤處理

當 API 存留在 Azure AD B2C 系統之外時，需要在技術設定檔內進行適當的錯誤處理。請確定使用者獲得適當的通知，且應用程式可以正常地處理失敗。

如何正常處理 API 錯誤

API 可能會因各種原因而失敗，請讓您的應用程式能夠從這類失敗中復原。傳回 HTTP 4XX 錯誤訊息，如果 API 無法完成要求。在 Azure AD B2C 原則中，請嘗試正常處理 API 無法使用的情況，可能會呈現較少的體驗。
正常處理暫時性錯誤。 RESTful API 設定檔可讓您設定各種斷路器的錯誤訊息。
主動監視並使用持續整合/持續傳遞 (CICD)，輪替 API 存取認證，例如技術設定檔引擎所使用的密碼和憑證。

API 管理 - 最佳做法

當您部署 REST API 並設定 RESTful 技術設定檔時，遵循建議的最佳做法可協助您避免常見的錯誤和忽視的問題。

如何管理 API

API 管理 (APIM) 會發佈、管理及分析您的 API。 APIM 也會處理驗證，以提供後端服務和微服務的安全存取。使用 API 閘道來擴增 API 部署、快取和負載平衡。
建議您在使用者旅程圖的開頭取得正確的權杖，而不是針對每個 API 呼叫多次並保護 Azure APIM API。

共用方式為