以我所主，为我所用

HATEOAS 项目逐字稿

4分钟阅读

HATEOAS 项目逐字稿

使用方式

  • 这页只保留 3 到 5 分钟版本 和 深挖版本。
  • 主轴固定是“资源契约、动作发现、前后端解耦”，不要讲成“我用了 HATEOAS”。
  • 这条线最适合在前端架构、资源驱动 UI、多消费端或 AI Agent 场景下展开。

3 到 5 分钟版本

如果让我用 3 到 5 分钟讲 HATEOAS，我不会把它讲成“后端多返回了几个 _links”，而会讲成：我在一个多消费端项目里，把前后端通信从“基于路径的接口调用”，升级成了“基于语义关系的资源导航和动作发现”。

这个项目要解决的核心问题，是前端大量手写 URL、手写动作、手写表单，导致接口一变，页面就很脆；同时不同客户端和 AI Agent 也很难共用一套 API 能力。后来我们让后端返回 HAL / HAL-FORMS 资源，除了数据本身，还提供关系链接和动作模板；前端则不再手工拼路径，而是通过 follow(rel) 做语义导航。

这里真正有价值的点，不只是后端改了响应格式，而是前端把这套模型真正消费起来了。我们抽出了独立的 TypeScript client 和 React hooks，让资源关系导航、分页关系消费、动作模板解析、请求去重和缓存都能围绕同一套资源语义工作。这样 breadcrumb、sidebar、动态表单这些 UI 能力，也可以随着资源关系一起长出来。

我觉得这条线特别适合 AI 和多消费端场景。因为普通 REST 更适合人类开发者对着文档手写调用，而 HATEOAS + HAL-FORMS 更适合客户端或 AI Agent 在运行时发现“当前这个资源还能做什么”。当然，这种设计也不是银弹，对简单后台系统可能偏重，所以我会把它讲成一个面向多消费端、动作可发现、接口演进频繁场景的工程化取舍。

所以如果总结 HATEOAS 这个项目，我会说我做的不是“用了一个 API 风格”，而是把前后端协作从路径耦合升级成了资源导航和动作发现，并且前端真正把这套契约消费成了可复用的工程能力。

深挖版本

关系图谱

反向链接