之前有前端要求我每个 api 接口对应页面让他不用动脑，我是按功能模块划分的，还说这样网络请求少性能好，但这个小项目不要求性能，使用的人很少，字段很少也有文档，同样的 api 接口不同页面都有调用。
不过我这个情况本质是他在摸鱼搞外包。。。

虽然耦合了很多业务，但是职责很单一，以后就只有这个用途，符合单一职责[狗头]。

这就是 curd boy 的作用了，拼好后给前端

盲猜，java ，不让用 map ，傻逼设计：要多加个不同字段，就得去改定义所在的 java 文件，或得增加一个 java 文件

“单独一次的请求肯定比两次性能好，万一有一个请求嘎了或者慢了， 表格数据就加载慢或者不出来了。”

单元素接口重复请求 n 次，跟批量请求一次，这种场景你的理由才站得住脚。设计上，接口之间要有正交性，也就是单一职责。

以前有些互联网公司，会招一些人，干聚合 API 的事情，通常是 PHP 岗，调内部(那时还不叫中台)服务接口，稍加处理返回给前端，甚至直接 PHP 输出 html 。

bff 就干这个的

看业务有多大。 如果是个高达 100 个账号用的系统，还是可以的。

后端接口确实时单一职责，不过可以有个聚合服务做拼凑。具体还是看公司习惯

以“前端按照业务逻辑状态渲染按钮”这个场景来说，以前可能喜欢返回一个 status 字段让前端根据 status 的不同值渲染不同样式的按钮。后来发现这种玩法前端经常来问字段含义，我还要结合需求给前端讲解，跟对端扯皮的功夫可能自己都做完了。
现在学聪明了，直接把渲染按钮需要的按钮文案、颜色之类的东西都给前端返回，就很少跟前端扯皮了，节省了大量的时间哈😄

这个分歧结果就是要么尽可能快的展示部分数据并逐步展示完整, 要么一次性展示所有数据.
如果接口性能好的话对用户来说感知不大, 如果部分性能不佳的话,性能最差的那部分就是瓶颈.

建议找技术主管拍板,谁拍板谁担责(虽然最后擦屁股的还得是一线开发)

我参与过的项目:两种实现都有. 有的是考虑解耦和复用就单独写,有的是考虑几种数据只会在一种统计页面展示就聚合到一起, 业务上没有绝对的界限说必须用哪种.
其他人的:多年前听说过雅虎的设计是尽可能一次返回减少 IO,这会儿没找到原文不知道说的啥场景.