与REST相比GraphQL是如何减少接口往返请求次数的？

你提到的REST需要两次请求的场景，在GraphQL中仅需1次请求即可完成，核心逻辑如下：

• GraphQL服务端通常只暴露单个统一的请求端点，不需要像REST那样针对不同资源切换不同的接口路径
• 支持直接在查询语句中定义需要的嵌套关联资源，服务端会在内部自动完成数据的拼接整合，不需要客户端逐层获取关联ID再单独发起请求

针对你举的具体场景，只需向GraphQL的唯一端点发送如下查询即可一次性拿到帖子+关联作者的全部信息：

query getPostWithAuthor($postId: ID!) {
  post(id: $postId) {
    # 按需声明需要的帖子字段
    title
    content
    createdTime
    # 直接嵌套查询关联的作者信息，无需单独传入authorId
    author {
      name
      avatar
      bio
      homepage
    }
  }
}

你只需在请求参数中传入目标帖子的$postId即可。服务端收到查询后，会先拉取对应postId的帖子数据，拿到内置的authorId后内部自动拉取对应作者的信息，最终将整合好的完整数据一次性返回给客户端，全程客户端仅需发起1次请求。

和REST的核心差异在于：REST接口的返回结构是服务端预定义的，单个接口通常仅返回单一资源的信息，关联资源必须由客户端主动获取ID后发起新请求；而GraphQL的返回结构完全由客户端的查询语句定义，只要服务端在Schema中定义了post和author的关联关系，客户端就可以一次性拉取所有需要的关联数据，完全避免了多次往返请求的开销。

内容的提问来源于stack exchange，提问作者ravindar tharanikumar