使用 Azure AD B2C 利用外部程序的復原介面
在本文中，尋找如何規劃和實作 RESTful API 的指引，讓您的應用程式對 API 失敗更具彈性。
確定正確的 API 放置
使用身分識別體驗架構 （IEF） 原則，使用 RESTful API 技術配置檔呼叫外部系統。 IEF 運行時間環境不會控制外部系統，這是潛在的失敗點。
使用 API 管理外部系統
呼叫介面來存取特定數據時，請確認數據會驅動驗證決策。 評估資訊是否對應用程式的功能至關重要。 例如，電子商務與次要功能 (例如系統管理) 的比較。 如果驗證不需要資訊，請考慮將呼叫移至應用程式邏輯。
如果驗證的數據相對靜態且很小，且不應該外部化，請將它放在目錄中。
可能的話，請從預先驗證的路徑移除 API 呼叫。 如果您無法，請針對 API 啟用阻斷服務 （DoS） 和分散式阻斷服務 （DDoS） 攻擊的保護。 攻擊者可以載入頁面，並嘗試使用 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。