UML 循序圖-API 驗證

圖解工程 · 驗證流程由一則提示生成
唯讀預覽

原始提示

建立 REST API 驗證流程的 UML 循序圖,包含用戶端、API 閘道、驗證服務與資料庫

做一份自己的版本

關於框架

追蹤瀏覽器與後端之間的登入流程

這個循序圖範例包含五個參與者:User、Browser、Backend API、OAuth Provider 與 DB。12 則訊息從「使用 Google 登入」開始,依序經過授權、同意、授權碼回呼、權杖交換、新增或更新使用者資料、設定工作階段 Cookie,最後重新導向至儀表板。

範例中的提供者會同時回傳存取權杖與 ID 權杖。圖中只呈現成功流程,不包含權杖驗證、請求關聯檢查、PKCE、拒絕同意、驗證碼過期或資料庫失敗等情況。回呼特別標示為 POST /auth/callback;這是範例應用程式中的步驟,請依照自己的實作進行調整。

利用這個循序圖釐清每個請求由誰發起,以及瀏覽器在哪個階段將工作交給伺服器。在將它視為設計規格前,請加入驗證步驟與其他結果分支。務必明確記錄通訊協定細節,以及應用程式特有的工作階段行為。

包含內容

你會得到

  • 涵蓋使用者、瀏覽器、後端、提供者與資料庫的五條生命線
  • 代表成功登入流程的 12 則有序訊息
  • 先交換授權碼,再新增或更新使用者資料
  • 最後顯示工作階段 Cookie 與重新導向至儀表板的訊息
圖解

UML 循序圖-API 驗證

uml循序圖API 設計

✦ Free preview · Sign in to use

常見問題

常見問題

這包含登入失敗的情境嗎?

不用。這 12 則訊息都屬於成功流程。若要涵蓋其他情況,請加入使用者拒絕同意、驗證碼無效或過期,以及使用者資料寫入失敗等分支。

提供者回傳權杖後會發生什麼事?

範例後端會新增或更新使用者資料、取得使用者物件,並設定工作階段 Cookie。範例沒有繪製權杖驗證或工作階段儲存的細節。

我的應用程式一定需要 POST /auth/callback 嗎?

這個標籤屬於範例內容。請依照你的提供者設定與後端路由,對應回呼訊息,並區分提供者重新導向與後續可能發生的瀏覽器對後端請求。

UML 循序圖-API 驗證

免費開始,無需信用卡。

Free preview · Sign in to use