API端点是否可返回多个模型？前端配置创建/更新表单的接口方案问询

单端点返回全部所需模型的方案 #

优势 #

• 仅需发起1次HTTP请求，网络开销更低，弱网环境下的表单加载速度优势明显
• 前端逻辑更简单，无需处理多请求并发调度、多接口异常兜底的协调问题
• 数据一致性更高，所有关联模型均为同一时间从数据库查询返回，不会出现不同步问题

潜在问题 #

• 接口复用性差，若其他业务场景仅需要其中某一类模型数据，该接口会返回大量冗余内容，额外浪费带宽
• 整体响应时间更长，服务端需要同时查询多个模型的数据源，任意一个查询逻辑变慢都会拖慢整个接口的响应速度
• 后续维护成本高，只要表单调整需要新增/移除关联字段，就要修改接口返回结构，若多个不同场景的表单共用该端点，很容易引发版本兼容问题

多端点单独拉取各表单项对应模型的方案 #

优势 #

• 接口复用性极强，每个端点仅返回一类模型数据，全项目所有需要同类数据的场景都可以直接复用，避免重复开发
• 单个接口逻辑简单、响应速度快，故障排查和迭代调整的成本极低
• 扩展灵活，表单新增关联字段时仅需新增对应接口调用，不需要调整已有接口的逻辑
• 支持按需加载，隐藏的、条件触发的表单项无需提前拉取对应数据，进一步降低不必要的资源消耗

潜在问题 #

• 浏览器对同一域名的并发请求数有限制（通常为6-8个），若表单依赖的模型数量过多，会出现请求排队，反而延长整体加载时间
• 前端逻辑复杂度更高，需要处理多接口的异常兜底逻辑，比如某一个接口请求失败时，要判断是禁用对应表单项还是重试、或是禁止整个表单提交
• 极端场景下可能出现数据不一致，比如先后拉取的两类关联数据中间刚好有后台更新操作，会导致两次拿到的数据版本不匹配

场景化最佳实践 #

没有通用的最优解，根据你的实际业务情况选择即可：

• 如果当前表单是独立业务场景，后续复用这些关联模型接口的概率极低，且表单依赖的模型数量少于3个，优先选择单端点方案，整体开发和维护成本最低
• 如果你正在开发中后台类的系统，有大量表单都会用到同类通用关联数据（比如部门列表、用户列表、分类标签等），优先选择多端点方案，同时配合前后端的缓存策略：服务端给低实时性的通用模型接口加合理的Cache-Control缓存头，前端做内存/本地缓存，同一个模型的数据仅需拉取一次，基本可以抵消多请求的性能劣势。

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