后端接口一定要保持单一职责吗

之前干前端的时候遇到一个需求就是需要用表格展示一些订单或者商品信息，但是跟我对接的后端哥们让我从两个接口拿。但是我想让他再单独出一个接口直接返回我所有的信息，这样我就不用请求两次接口再拼装展示到表格中；
我的想法就是：
单独一次的请求肯定比两次性能好，万一有一个请求嘎了或者慢了， 表格数据就加载慢或者不出来了。

后端那哥们的想法是：接口需要保持单一职责，再单独出一个接口就重复了。

当时刚到那家公司，也没劲跟这哥们扯犊子，不过他给的理由我也无办法反驳，但是我感觉我的想法也是对的。

大佬们遇到这种情况，最佳的做法应该是咋样的啊。

前后端都写的人表示，还是分成两个接口吧，你写代码都要解耦，请求接口不也一样嘛，如果拼接成一个接口然后这个接口只能这个功能专用也不合适吧？你请求的时候可以并发请求，又不是非得一个一个进行

接口是要保持单一职责，但是也可以抽一层 api 出来 聚合后端接口；毕竟后端之间走内网，前后端走公网

所以，才有了 BFF
https://bff-patterns.com/

要么你前端老大撕逼能力强，让后端根据你前端 ViewModel 写一堆聚合接口

要么你推后端去用 GraphQL ，虽说如果真的按照它去设计，很多时候这玩意很难用，但你用它包一下，一次请求调俩接口还是很容易的。

但对于后端来说，不去维护多个功能过于类似的接口是基本素养。

需要，除非你现在开发的项目是后端的唯一前端。

标题的结论应该是“尽可能”，不过你的场景中，你没有说清楚具体的内容，其实很难判断到底后端所谓的单一职责，划分是否合理，不少后端其实爱把一些本来应该更紧密耦合的东西，强行分开，就为了自己有时候更简单而已

架构的魅力：平衡的艺术，在不同需求之间找到平衡点非常重要。
https://i.imgur.com/2hpuKvd.png

如上所述，BFF 就是干这个的，GraphQL 也可以解决。

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

写个聚合接口就完了