如何设计无需客户端多次请求即可获取数据的REST API？

哈哈，这个场景我之前做企业内部系统的时候刚好碰到过！完全有遵循REST原则的方法来减少客户端的请求次数，而且新建/api/employeesByDepartment端点并不是唯一甚至最优的选择，下面给你分享几种更贴合REST设计理念的思路：

1. 扩展现有/api/employees的查询能力 #

你可以给现有的员工端点加个灵活的查询参数，让客户端能一次性拉取所有部门的员工，同时带上部门信息：

• 比如支持/api/employees?department=all：后端识别这个参数后，返回所有员工，并且在每个员工对象里嵌入对应的部门基础数据（比如department_id、department_name），这样客户端拿到数据就能直接拼接表格，不用再单独请求部门接口。
• 还可以支持批量部门ID查询：/api/employees?department=21,23,45，如果客户端能提前拿到需要的部门ID列表，一次请求就能搞定多部门的员工数据。

这种方式的好处是复用了已有的资源端点，完全符合REST“围绕资源设计”的核心，不用额外维护新的接口逻辑。

2. 在部门端点嵌入关联员工数据 #

另一种思路是调整/api/departments的返回结构，让客户端请求部门列表时，直接拿到带员工信息的完整数据：
比如请求/api/departments返回的结构可以是：

[
  {
    "id": 21,
    "name": "技术研发部",
    "employees": [
      {"id": 1001, "name": "王明", "position": "Java开发"},
      {"id": 1002, "name": "李娜", "position": "前端开发"}
    ]
  },
  {
    "id": 22,
    "name": "市场部",
    "employees": [
      {"id": 2001, "name": "张伟", "position": "品牌推广"}
    ]
  }
]

如果担心默认返回这么多数据会影响性能，可以加个可选参数控制是否嵌入员工，比如/api/departments?embed=employees——默认只返回部门基本信息，需要关联数据时再带上这个参数。这种设计完全符合REST中资源关联的处理方式，客户端一次请求就能拿到所有需要的拼接数据。

3. 关于新建/api/employeesByDepartment的思考 #

如果上面两种方案都不适合你的业务场景（比如嵌入数据会导致返回体过大，或者现有端点的逻辑已经非常复杂），新建这个端点也不违反REST原则，但要注意两点：

• 保持资源语义一致：这个端点本质上是员工资源的一种聚合视图，返回的员工数据结构要和/api/employees保持一致，避免客户端需要适配不同的数据格式。
• 避免过度创建这类“专用”端点：不然API会越来越臃肿，后期维护成本很高。

总的来说，优先考虑扩展现有端点或者嵌入关联数据，这两种方式更贴合REST的设计理念，也能有效解决请求次数过多的问题。

内容的提问来源于stack exchange，提问作者D.C.