article { title author { name } }REST 资源建模
作者 · 林晓
views / avatar 未请求，不出现
数据与服务 · 服务与数据
GraphQLGraphQL
GraphQL 让客户端在一条查询里声明字段；回卡只填要的栏，嵌套关联也一起拿。
先认出这张查询单，再看回卡填了几栏
下面就是客户端写出的查询和同一张回卡。默认只要标题和作者名。把全表塞回或让作者字段失败，变化都长在这张回卡上。
只回 2 个字段：回卡只长出声明过的栏。
原因：查询单声明了 title 和 author.name，回卡只填这两栏。下一步：试「把全表塞回来」，看多余字段怎样撑满回卡。
知识点：声明哪些字段，就只拿哪些字段
回卡上的栏已经演示了核心关系，这里只给可复用的命名。
- 单端点：不问一堆 URL，在一条 query 里声明要的字段。
- 按需：未声明的 views、avatar 不会出现，避免过度获取。
- 嵌套：author.name 和文章标题一次拿回，不必再打第二个接口。
- 字段级失败：data 与 errors 可并存，标题仍在，作者名单独标失败。
什么时候用、怎么用
一次页面要拼多个资源的少量字段，或 REST 会过度获取时，才考虑 GraphQL。
- 信号：文章卡只要标题和作者名，却被迫拉完整用户对象。
- 适用：客户端形状多变、嵌套关联多、想减少往返。
- 不适用：资源动作本身很清楚、缓存和 HTTP 语义更重要——REST 往往更简单。
- 最短路径：写出要的字段 → 执行 → 看回卡是否只含声明栏 → 失败看 path，不要丢掉整张卡。
正反例：同一张文章卡，只换怎么取字段
目标都是展示标题和作者名，只改一次按需查询还是两条 REST 全量返回。
回卡只有 title 和 author.name。没有阅读量，也没有头像地址。
多一次往返，还夹带 views 和 avatar。回卡被撑满，调用方自己再挑。
快速自测
文章卡只要标题和作者名。用 GraphQL 时，阅读量没声明，响应里会怎样？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。