长春企业开发外贸网站时，搜索框和询价表都看起来是输入后点按钮，但它们执行的任务不同。搜索通常读取资料，询价可能创建记录并触发通知。应先定义动作和数据处理，再选提交方式，不能把能跳转的搜索样例直接复制为接收客户需求。
先确定这次请求有没有业务动作
MDN说明原生表单GET将数据附加到动作URL，适用于没有副作用的查询；POST把表单数据放在请求体。若脚本拦截后自行发送，则要检查实际请求，不能仅从HTML里的method推断全部行为。
| 任务 | 候选设计关注 | 不能省略 |
|---|---|---|
| 查找公开资料 | GET查询可形成可分享的结果地址 | 查询词与实际结果关系 |
| 保存需求 | 按真实接口设计创建动作 | 服务器验证、授权边界与准确反馈 |
| 触发通知 | 单独明确是否发生 | 任务状态与重复处理 |
| 使用自定义脚本 | 检查真正发送的方法和内容 | 不只看表单标签 |
两个离线样例只用示意资料
<form action="/demo-search" method="get">
<label>查询 <input name="q" value="DEMO-CATALOG"></label>
<button type="submit">查询</button>
</form>
<form action="/demo-request" method="post">
<label>示意对象 <input name="model" value="DEMO-A"></label>
<button type="submit">提交演示</button>
</form>请求记录怎样对应演示值
| 方法 | 示意位置 | 核对目的 |
|---|---|---|
| GET | URL查询中q=DEMO-CATALOG | 确认读取条件 |
| POST | 请求体中model=DEMO-A | 确认发送位置，接收仍另验 |
| 脚本自定义 | 按真实网络请求记录 | 不从页面外观推断方法 |
看实际请求，再看实际结果
1动作定义读取还是创建。
2请求核对方法和数据位置。
3处理确认服务器执行的范围。
4反馈按真实成功或失败说明。
- 使用明确标注的示意字段，记录实际方法、目标与数据。
- 把读取结果与创建记录分别验收。
- 如果有跳转，记录初始请求和最终到达，不混为一步。
- 保留失败和未知状态，不以页面动画代替处理结果。
搜索结果地址能分享就说明设计完成了吗？
还要核对查询内容、结果范围和返回体验，不能只看地址变化。
在开发工具看到请求体，能证明销售收到需求吗？
不能，仍需核对保存与通知等真实处理节点。