營運與維護 · 實作指南
介面換了地址，預訂動作還在嗎？三張重定向驗收卡
用三張驗收卡核對重新導向的方法、回執與資料接收授權，避免將成功頁面誤認為預訂成立。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 澳門粵語逐字稿
網頁開啟了，預訂卻沒有成立
設想一家美國設備租借店，把舊預訂介面遷到新地址。自動化傳送預訂後，最終收到成功頁面，於是通知客戶“已預留”。但頁面能開啟，不等於設備已被鎖定。這是假設案例，不是客戶事故報告。本文用一次遷移驗收，拆開地址變化、請求動作和業務結果三個問題；不是新的產品釋出，也沒有實際執行客戶測試。
- 地址變化：到哪裡？
- 請求動作：做什麼？
- 業務回執：預留了嗎？
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第一張驗收卡：方法有沒有變
RFC 9110 允許客戶端在處理 301 或 302 時，將後續 POST 改成 GET；307 和 308 則保留方法，分別表示臨時和永久重定向。[1][2] 因而驗收不能只記最終狀態碼。請在隔離測試環境記錄每一跳的地址、方法以及測試請求體是否到達。不要把真實客戶資料寫進除錯日誌。
- 301 / 302：POST 可能變 GET
- 307 / 308：保留請求方法
- 驗收：逐跳看方法與測試請求內容
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第二張驗收卡：看回執，還是重發動作
303 表示去另一個資源讀取間接結果，並非要求把原動作再做一次。[3] 對租賃店而言，預訂寫入後檢視回執，可以與把尚未處理的預訂轉交新介面分開設計。這裡是架構建議，不是說所有預訂系統都採用同一模式。先寫清每個地址負責“執行”還是“展示”，再決定客戶端遇到跳轉應做什麼。
- 執行入口：處理預訂
- 303：去讀取另一個資源
- 展示入口：檢視回執，不再建立
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第三張驗收卡：目標能不能收這份資料
保留方法不是轉發授權。建議把允許的目標域名和路徑列進遷移清單：未知地址、降級到非加密連線或循環跳轉跳轉，都停止自動跟隨並交給負責人。驗證客戶端不會把敏感頭或正文送往未批准目標；不要為了讓測試通過而強行保留認證頭。此處是風險控制建議，不是對某款客戶端預設行為的保證。
- 批准的目標：才可繼續評估
- 未知地址 / 降級 / 迴圈：停止
- 敏感頭與正文：不向未批准目標傳送
已接受的區域說明圖重繪，並非未經修改的原始截圖。
把三種結果放在同一張表上
建議測試三個明確場景：舊地址轉到批准的新介面，檢查同一測試預訂的業務回執；寫入後轉向回執頁，檢查沒有再次建立；遇到未批准目標，檢查安全停止且沒有傳送正文。每條記錄同時寫“預期動作、實際鏈路、最終預訂狀態”。這些是待執行的驗收用例，不是已經通過的結果。
- 批准轉發 → 核對同一預訂回執
- 寫入後跳轉 → 檢查沒有再次建立
- 未批准目標 → 檢查安全停止
已接受的區域說明圖重繪，並非未經修改的原始截圖。
上線前只問一個業務問題
讓負責人回答：客戶收到確認時，哪份證據證明這臺設備已預留？答案應指向可核對的預訂識別碼和狀態，而非瀏覽器地址或綠色成功頁。保留舊、新入口的測試證據，明確異常時由誰核查，再決定遷移是否可放行。不要用反覆提交來猜測結果；結果不明時先對帳，避免同一需求變成兩筆預訂。
- 證據：預訂識別 + 狀態
- 責任：誰來核查異常？
- 不明結果：先對帳，不盲目重提
已接受的區域說明圖重繪，並非未經修改的原始截圖。