营运与维护 · 实作指南
接口换了地址，预订动作还在吗？三张重定向验收卡
用三张验收卡核对重新导向的方法、回执与资料接收授权，避免将成功页面误认为预订成立。
AAHouse 原创解说视频，采用 AI 辅助概念画面、合成旁白及原创音乐。
英文逐字稿 · 简体中文普通话逐字稿 · 台湾华语逐字稿 · 澳门粤语逐字稿
网页打开了，预订却没有成立
设想一家美国设备租赁店，把旧预订接口迁到新地址。自动化发送预订后，最终收到成功页面，于是通知客户“已预留”。但页面能打开，不等于设备已被锁定。这是假设案例，不是客户事故报告。本文用一次迁移验收，拆开地址变化、请求动作和业务结果三个问题；不是新的产品发布，也没有实际执行客户测试。
- 地址变化：到哪里？
- 请求动作：做什么？
- 业务回执：预留了吗？
未经修改的原始来源说明图。
第一张验收卡：方法有没有变
RFC 9110 允许客户端在处理 301 或 302 时，将后续 POST 改成 GET；307 和 308 则保留方法，分别表示临时和永久重定向。[1][2] 因而验收不能只记最终状态码。请在隔离测试环境记录每一跳的地址、方法以及测试请求体是否到达。不要把真实客户资料写进调试日志。
- 301 / 302：POST 可能变 GET
- 307 / 308：保留请求方法
- 验收：逐跳看方法与测试正文
未经修改的原始来源说明图。
第二张验收卡：看回执，还是重发动作
303 表示去另一个资源读取间接结果，并非要求把原动作再做一次。[3] 对租赁店而言，预订写入后查看回执，可以与把尚未处理的预订转交新接口分开设计。这里是架构建议，不是说所有预订系统都采用同一模式。先写清每个地址负责“执行”还是“展示”，再决定客户端遇到跳转应做什么。
- 执行入口：处理预订
- 303：去读取另一个资源
- 展示入口：查看回执，不再创建
未经修改的原始来源说明图。
第三张验收卡：目标能不能收这份数据
保留方法不是转发授权。建议把允许的目标域名和路径列进迁移清单：未知地址、降级到非加密连接或循环跳转，都停止自动跟随并交给负责人。验证客户端不会把敏感头或正文送往未批准目标；不要为了让测试通过而强行保留认证头。此处是风险控制建议，不是对某款客户端默认行为的保证。
- 批准的目标：才可继续评估
- 未知地址 / 降级 / 循环：停止
- 敏感头与正文：不向未批准目标发送
未经修改的原始来源说明图。
把三种结果放在同一张表上
建议测试三个明确场景：旧地址转到批准的新接口，检查同一测试预订的业务回执；写入后转向回执页，检查没有再次创建；遇到未批准目标，检查安全停止且没有发送正文。每条记录同时写“预期动作、实际链路、最终预订状态”。这些是待执行的验收用例，不是已经通过的结果。
- 批准转发 → 核对同一预订回执
- 写入后跳转 → 检查没有再次创建
- 未批准目标 → 检查安全停止
未经修改的原始来源说明图。
上线前只问一个业务问题
让负责人回答：客户收到确认时，哪份证据证明这台设备已预留？答案应指向可核对的预订标识和状态，而非浏览器地址或绿色成功页。保留旧、新入口的测试证据，明确异常时由谁核查，再决定迁移是否可放行。不要用反复提交来猜测结果；结果不明时先对账，避免同一需求变成两笔预订。
- 证据：预订标识 + 状态
- 责任：谁来核查异常？
- 不明结果：先对账，不盲目重提
未经修改的原始来源说明图。