平面REST API（无嵌套关系）

Question

主题外/重复

• Many asynchronous calls vs single call to the API
• Many small requests vs. few large requests (API Design)
• REST API Design: Multiple calls vs. single call to the API

原始

这是个好主意吗？

例如：

// http://example.org/api/posts

[
  {
    "title": "Title one",
    "user_id": 1
  },
  {
    "title": "Title two",
    "user_id": 1
  },
  {
    "title": "Title three",
    "user_id": 2
  }
]

然后提出另一个请求：

// http://example.org/api/users?filters={ids: [1, 2, ...]}

[
  {
    "id": 1,
    "name": "John"
  },
  {
    "id": 2,
    "name": "Vanessa"
  }
]

专业人士

1. 简单的REST API设计（扁平）
2. 更简单的客户端代码（没有normalizr /已经“规范化”）
3. 服务器上每个端点的开销较少（无需加载关系）
4. 不同端点之间没有“重复” HTTP资源加载（不可避免）
5. 在给定的端点响应（较小的有效负载）内没有重复的实体数据–例如：在user = 1响应中，/posts（约翰）嵌套数据将出现两次

缺点

1. 更多对服务器的HTTP请求–尽管可以通过良好（且更轻松）的缓存策略来缓解这种情况
2. GraphQL（较新的技术）不会促进平坦响应

注意： 还可以考虑将两种方法混合使用。

问题

击中服务器的请求多而不是请求少，但是负载响应却高呢？