简历追问：HATEOAS 资源动作契约消费层设计

关联：全栈工程师简历 > HATEOAS 资源契约架构、15分钟：HATEOAS 资源契约架构、HATEOAS 接口在后端的性能组装与状态机校验、HATEOAS架构下的多级缓存设计与一致性保证。

对应简历描述

主导前端 HATEOAS 消费层，将当前资源可执行的动作通过 _links / _templates 与资源状态一起返回，前端基于 relation 与 action 消费契约，降低状态机规则在多端重复实现带来的联动改动与测试回归成本。

面试官真正想确认

你是不是只会说“HATEOAS 不写死 URL”，还是确实处理过多端状态机漂移、按钮权限不一致、payload 规则散落这些真实问题。

连续追问链

1. 业务现场

• 当时是哪类资源最先暴露状态机漂移？审批单、订单、合同还是其他对象？
• 原来前端里有哪些 status / role / permission 判断？能举一个真实按钮或动作吗？
• Web、小程序、App 之间出现过什么不一致？测试是怎么发现的？
• 你怎么判断这个问题不是“封装一个 API Service”就能解决？

2. 契约设计

• _links 和 _templates 各自承载什么？为什么动作提交不能只放在 _links 里？
• relation name 怎么命名和治理？approve、submit、cancel 这类 relation 是否有全局字典？
• “没有返回某个动作”在 UI 上代表隐藏、禁用，还是提示无权限？这个语义谁定义？
• payload schema 里如何表达必填、枚举、格式、默认值和服务端校验错误？

3. 前后端边界

• 后端如何计算当前资源可用动作？角色、租户、状态机、数据归属谁优先？
• 列表接口返回 100 条资源时，会不会每条都实时查权限导致 N+1？
• 前端拿到过期契约后提交动作，服务端返回 409 或 403，UI 怎么恢复？
• 契约版本升级时，如果 relation 改名，老前端怎么兼容？

4. 落地证据

• 能否展示一个改造前后的组件片段：从多重 if-else 到 state.hasLink()？
• 有没有契约测试覆盖不同角色、状态、租户组合？
• 改造后测试回归范围是怎么收敛的？不要只说“成本降低”，要说口径。

场景推演题

现在有一张报销单：申请人、直属经理、财务、管理员在 draft / pending / approved / rejected 下能做的动作不同。请你设计一个返回资源，并说明前端如何渲染按钮。

继续追：如果后端新增“撤回”动作，Web 端不发版能不能出现？如果旧 App 不认识这个 relation，会发生什么？

容易露馅的回答

• “就是后端返回一个按钮数组，前端遍历渲染。”
• “权限还是前端判断，HATEOAS 只是少写 URL。”
• “后端把所有动作都返回，前端自己过滤。”
• “接口挂了就提示失败，没有其他状态设计。”