HATEOAS 作为面试项目怎么讲
使用方式
- 这页是
HATEOAS 项目逐字稿的深挖稿，默认不要整页背，挑 1 到 2 个点展开即可。 - 结构固定按“资源导航 → 动作发现 → 前端消费层与工程取舍”来讲。
- 简历版统一看 全栈工程师简历成品版（可直接改） > HATEOAS 请求管理。
一句话定性
不要把这个项目讲成“我用了 HATEOAS”，而要讲成“我把前后端通信从基于路径的接口调用，升级成了基于语义关系的资源导航和动作发现”。
推荐主线
我讲这条线时，通常只讲三件事。第一是资源导航，也就是前端不再手写 URL，而是通过关系语义去发现下一步资源。第二是动作发现，也就是后端不只返回数据，还返回 HAL-FORMS _templates，让前端或 AI Agent 知道当前资源能做什么。第三是前端消费层，我不是只改后端格式，而是真正把这套资源契约抽成了 TypeScript client 和 React hooks。
最容易被追问的 3 个点
- 为什么不直接手写 URL / 普通 REST 不够吗
- 前端到底做了什么，不只是后端返回
_links吧 - 为什么这种设计特别适合 AI / Agent 场景
深挖点 1：为什么要做资源导航
我会说，因为多消费端场景下，前端大量手写路径、手写动作、手写表单，接口一变就很脆。如果前端通过 follow(rel) 这类关系语义导航，后端只要保证关系语义稳定，路径结构就可以演进，前端修改面会小很多。
深挖点 2：动作发现到底解决了什么
这个项目不只是返回数据，还返回 HAL-FORMS _templates，让前端或 AI Agent 能发现“当前资源能不能更新、该用什么方法提交、有哪些字段、哪些字段必填”。这样表单、动作面板和 AI 执行能力就可以基于资源契约通用化，而不是全部写死在页面里。
深挖点 3：前端消费层到底做了什么
我做的不是后端多返回几个 _links 就结束了，而是把前端消费层真正抽象起来了。我们有独立的 @hateoas-ts/resource 和 @hateoas-ts/resource-react，资源对象支持 follow(rel)、缓存、请求去重、分页关系消费，React 层再封装 useResource、useInfiniteCollection 这些 hooks。所以这不是概念验证，而是一条完整链路。
如果面试官追问“为什么它适合 AI / Agent 场景”
我会说，普通 REST 更适合人类开发者对着文档手写调用，而 HATEOAS + HAL-FORMS 更适合客户端或 AI Agent 在运行时发现“当前这个资源还能做什么”。也就是说，它天然更适合多消费端、动作可发现和接口演进频繁的场景。
一个很好用的落地例子
如果面试官觉得 follow(rel) 还是太抽象，我会补一个很接地气的例子：我们连页面壳层都在按资源关系拿。比如前端拉项目页时会带 Prefer: layout=sidebar, layout=breadcrumb，让后端顺手把 sidebar 和 breadcrumb 的导航资源一起返回。这样前端不是每个页面自己拼导航，而是直接按资源关系去渲染壳层。
最后一句收口
所以如果让我收一句，我会说这个项目最适合的包装方式不是“我会 HATEOAS”，而是“我把前后端协作从路径耦合升级成了资源导航和动作发现，并且前端真正把这套模型消费起来了”。