REST API 为具有聚合属性的资源设计

Question

我们目前正在尝试提出一套适合我们资源模型的 REST API。

资源的简化示例是：

CompanyInfo: {
   totalNumberOfEmployees: Number,
   employees: [...employees],
}

Employee: {
   name: String,
}

在这种情况下，“CompanyInfo”就像数据库中不存在的虚拟资源。这是获取与公司资源相关的所有数据的捷径。其想法是减少 FE 上的逻辑量并创建更方便的端点。

我们当前的端点设计是：

   GET /api/companyInfos/{companyId}/employees

   GET,POST,PUT,DELETE /api/companyInfos/{companyId}/employees/{employeeId}

额外的 {companyId} 的原因是因为这些端点不返回“Employees”，而是返回一个“CompanyInfo”，其中包含嵌入在有效负载中的“Employees”。

这是为了避免聚合属性“totalNumberOfEmployees”在我们调用 POST 以创建新的“Employee”时不会更新

所以我的问题是：

• 这是解决“请求过多”或“FE 中逻辑过多”问题的正确做法吗？

• 端点返回与其 url 描述的完全不同的资源是否可以接受？

非常感谢:)

Answer 1

关于你的拳头问题

这是解决“请求过多”或“FE中逻辑过多”问题的正确做法吗？

是的 有时这就是我们应该做的。当每个请求中发送的数据很小时。许多请求不会影响性能，所以这就是假设的方式。

一般建议在前端编写一个单体Ajax调用，它可以进行任何类型的调用，将回调作为参数，将方法、参数作为参数。

因此，如果您遵循这种方法，它不会有太多的逻辑。您只需编写每个 Ajax 调用的回调。有时情况可能不允许此示例：如果您使用“多部分/混合”之类的内容类型 在那里你必须编写另一个ajax调用代码

然而现在大多数前端有太多基于交互网站的逻辑。所以你最关心的应该是网站的外观。

第二个问题

端点返回与其 url 描述的完全不同的资源是否可以接受？

是的。它是可以接受的 。但建议客户端在 Accept 标头中提及它期望的所有 MIME 类型，并且只有那些 MIME 类型应该由 Api 返回。