具有外部進程的復原介面
在本文中，我們會提供如何在使用者旅程中規劃和實作 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 可能會因為各種原因而失敗，讓您的應用程式能夠復原這類失敗。 如果 API 無法完成要求，則傳回 HTTP 4XX 錯誤訊息 。 在 Azure AD B2C 原則中，嘗試正常處理 API 無法使用，並可能呈現降低的體驗。
主動監視及使用持續整合/持續傳遞 （CICD），輪替 API 存取認證，例如技術設定檔引擎 所使用的 密碼和憑證。
API 管理 - 最佳做法
當您部署 REST API 並設定 RESTful 技術設定檔時，遵循建議的最佳做法可協助您避免不犯常見的錯誤和忽略事項。
如何管理 API
API 管理 （APIM） 發佈、管理和分析您的 API。 APIM 也會處理驗證，以提供後端服務和微服務的安全存取。 使用 API 閘道來相應放大 API 部署、快取和負載平衡。
建議是在使用者旅程圖開始時取得正確的權杖，而不是針對每個 API 呼叫多次，並 保護 Azure APIM API 。