第 7 章　API 使用申請與授權審核

• 讓會員對一個已發布的版本提出使用申請，填寫用途、希望的有效期間、每日額度與權限範圍。
• 說明「審核結果」跟「使用權」為什麼分開存放，並在同一個頁面把兩者並排顯示給會員看。
• 核准的同一個交易裡完成「申請標為核准＋寫審核紀錄＋建立使用權」，並讓管理員可以核准比申請更短的期間或更少的額度。
• 用資料庫規則擋住重複送出、重複核准，並實測兩個同時發生的請求真的只會產生一筆使用權。
• 撤銷使用權時只改授權狀態，原本的申請與核准紀錄完全不受影響。

要先完成第 6 章：已經有服務發布出來可以申請。理解上一章的「版本號欄位」跟「衝突例外」，本章會用同樣的模式再做一次類似的併發保護。

第 1 章講過的驗收金句：「註冊成功不代表能呼叫 API」。這一章把它變成真正的程式：會員要呼叫某個已發布的版本，必須先提出申請、說明用途，由管理員判斷是否合理，核准後系統才會建立一筆「使用權」。管理員看得到申請人填的用途、希望的期間跟額度，可以核准、把數字調低，或直接駁回。

申請跟使用權都綁定明確的版本，不是綁服務名稱——舊版核准了，提供者之後發布的新版本仍然要重新申請，新版本不會自動繼承舊版的核准。

看這張圖要注意重點：撤銷或到期時，改變的只有使用權，申請本身永遠維持「已核准」的紀錄。這樣分開存放有三個好處：①稽核方便——半年後查「當初為什麼准了」，答案在審核紀錄裡，就算使用權早已撤銷；②判斷「現在能不能用」只需要看使用權這一張表，不必翻歷史；③撤銷後如果想重新申請，可以產生全新的一組申請與使用權，舊的那一組完整保留當作歷史紀錄。

示範情境：一位會員對某個服務提出使用申請；管理員審核另一位會員的重新申請，並且把額度調低；最後在「我的申請與授權」和後臺「使用權管理」兩個畫面，看審核結果跟使用權如何分開呈現。

老師特別帶大家看一個真實案例：某位會員之前申請並取得了一支服務的使用權，後來被管理員以「用途已結束」為由撤銷。當這位會員重新申請時，「我的申請與授權」頁上會同時出現兩筆紀錄——舊的一筆（已核准／已撤銷）完整保留，新的一筆（審核中／尚無授權）獨立產生，兩者互不影響。

步驟一：申請的權限範圍與併發保護

幫使用申請資料表加上「權限範圍」欄位跟「版本號」欄位，並加一個帶篩選條件的唯一性限制：同一個人對同一個版本，只能有一件待審中的申請。

步驟二：送出申請

會員送出申請前，服務層要逐一檢查：版本必須是已發布狀態（審核中、已下架的版本一律拒絕）；用途、天數、額度、權限範圍都要落在合法範圍內；如果已經有一筆有效期使用權，就直接拒絕（避免額度被相加）。這些檢查都不信任前端表單，因為表單驗證可以被繞過，一定要在伺服器端重新做一次。

步驟三：審核與撤銷

核准、駁回共用的前提檢查：申請必須還是待審狀態、審核者不能是申請人本人；核准時另外要求版本仍然是已發布狀態（如果服務已經下架，只能駁回、不能核准，讓案件可以結案）。核准的動作要在同一次存檔裡完成「申請改為已核准」「新增審核紀錄」「新增使用權（有效期從現在起算）」三件事。撤銷則只做三件事：把使用權狀態改成已撤銷、記下撤銷時間與原因、寫一筆稽核紀錄——完全不去動申請與審核紀錄。

步驟四：個人進度與使用權管理頁面

「我的申請與授權」頁要把每一件申請跟它可能產生的使用權排在同一列顯示，即使某些申請還沒有審核結果、或被駁回而沒有使用權，也要能正常顯示出來（用資料庫的「外部連接」查詢手法，讓沒有配對到資料的那一側顯示空白，而不是整列消失）。

1. 核准才會建立使用權：送出一件申請後查詢，使用權筆數是 0；核准後變成 1；被駁回的申請則始終是 0。
2. 同一案件重複送出不會建立重複申請：同一個版本連續送出兩次（包含同時送出），待審中的申請只會有 1 件。
3. 同一案件重複核准不會建立重複權限：兩個工作階段同時核准同一件申請，一個成功、一個得到衝突訊息；事後再核准一次得到「不能重複審核」。使用權跟審核紀錄對這件申請都應該各只有 1 筆。
4. 反向驗證：直接對資料庫嘗試替一件已經有使用權的申請再新增一筆使用權，必須被唯一性限制擋下。