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

[chenxiaolani]

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

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

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

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

[esee]

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

[goodSleep]

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

[nikenidage1]

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

[Mithril]

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

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

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

[IvanLi127]

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

[ShuWei]

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

[GeekGao]

架构的魅力：平衡的艺术，在不同需求之间找到平衡点非常重要。

[billzhuang]

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

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

[tairan2006]

写个聚合接口就完了

[way2create]

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

[fffq]

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

[lizy0329]

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

[xiangyuecn]

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

[sagaxu]

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

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

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

[zoharSoul]

bff 就干这个的

[hefish]

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

[Kenyore]

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

[Orlion]

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

[Foxkeh]

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

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

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

[sophos]

https://github.com/sysulq/graphql-grpc-gateway

所以我试着做了一个 graphql 转 grpc 的网关，各个模块提供 grpc 接口即可，在网管层合并为 graphql ，端上可以根据需求自行选择接口聚合