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

[chenxiaolani]

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

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

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

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

[chenxiaolani]

@nikenidage1 @billzhuang @zoharSoul 好像想起来我之前呆过一家公司后端 php,但是前后端之间加了一层 node,前端只请求 node 服务，node 再调 php,这里 node 就是 BFF 层吧。

[Irisxx]

我就是因为和你碰到一样的问题，自己学 Node 写了聚合 ，挺方便的，求人不如靠自己。

[zoharSoul]

@chenxiaolani #21 嗯 或者说业务网关层. 一般都有这种玩意. 同语言的, 不同语言的. 有团队是前端负责, 有团队是后端写...
反正都少不了这个东西把各个服务的接口聚合后丢出去...

[flmn]

如果你的前端是 web ，那么尽量保持单一职责；如果你的前端是 app ，那么尽量合并接口（ bff ）。
说来说去，还是看前后端谁能说服谁。

[chenduke]

所以一个项目需要一个技术负责人去平衡技术实现的一些细节。 不然前后端分离导致的前后端经常撕逼的问题基本无解。 毕竟但凡有点老资格或者工作久点的程序员都想装逼。

[lux182]

这里还是初级程序员多啊

[zbowen66]

这无所谓吧，不是你拼就是他拼，我更倾向于 API 解耦。在前端封装一个函数调用多个 API 不就行了。

[laminux29]

因为要处理性能问题，计算机里有大量违反原则的事情，比如 CDN 、Cache/Buff 、各种冗余比如表字段冗余等等。

楼主要多思考。

[jonsmith]

当有话语权时，坚持接口单一职责；当只是个 curd boy 时，大佬们需要什么数据我返什么数据，复制粘贴多大点事。

技术从来不是单纯的技术，要保持灵活性，因人而异。

[huangzhiyia]

后端一个 API 对应只有一个项目一个功能的场景随意

可是真实场景哪有这么简单，一般都是对应几个服务或者几个前端依赖这个 API

某个前端偷懒说这不合理要求改动 API 这不是疯了

除非有重大性能问题或者业务破坏性变更，前端能自己处理就自己处理

处理不了的再和后端商量专门写一个新接口

下线一个 API 都要看过去七天甚至一个月半年有没有请求记录才敢下线。

已经部署到生产环境的 API 轻易不要妄动

[kyznever]

作为前后端都写的研发，从我个人思考和实践出发而言

先说做法：

- 后端 Controller 层：原先两个 Controller 保留，此外我会新增一个聚合的 Controller ，然后新的 Controller 基于原先两个 Controller 的具体实现。

原因：
1. 如果我们的前端是多端多服务的，我写一次，各个前端（ Web 、APP ）其实不用做多次重复的工作
2. 假设一个 http 网络请求在联通中只有 99% 的成功率，这个聚合 API 是 3 个 API 组合而成的。那么成功率一个是 99%，一个是 0.99 * 0.99 * 0.99 = 97%

[nino]

他没理解什么叫单一职责，这说的都不是一个“接口”，你们碰到的接口是 API endpoint ，实际上这个原则说的是 Interface ，Interface 当然要单一职责

[Bingchunmoli]

@GeekGao 我觉得不一定对，因为有的单个接口是一个接口实现了多个接口的功能，那么业务代码可能是耦合的导致维护难度和复杂度更高的可能

[Bingchunmoli]

@xiangyuecn 建议全用 any

[xomix]

人一定要吃的健康吗？我就喜欢吃烧烤。但是聚餐考虑就是大家协商解决。

[dif]

这是理想情况，我自己会坚持单一原则，但实际上 6 成以上的接口都不是单一的。业务决定的，没办法。真要坚持单一原则，那接口数量大约要膨胀 5 倍。前端不乐意了。

[yrj]

@kyznever 作为全栈，也比较赞同你的说法，还有一种情况上，前后端分离下，一个页面要做 ssr ，多次请求会增加 http 连接，性能上也会有些影响。

[dcdlove]

简直就是荒谬，一天天堆屎还堆出优越感了，接口不能满足前端就是垃圾，你就是吃这碗饭的，写不出来满足不了就是自己能力不行，别给自己找借口，拿什么规范原则做挡箭牌，真是丢死人，不行就转行挑大粪去

[R4rvZ6agNVWr56V0]

@Bingchunmoli 没有对错之分，如果实在纠结，那可以从当前人力配备和项目时间管理的角度来看问题。

[justdoit123]

这种不能简单通过谁方便、请求多少来考量。举个例子。

复杂详情页面。比如，商品的详情页面。

详情页面大概会有如下内容：
a. 商品自身的信息；
b. 优惠 & 活动；
c. 评论（列表）；
d. 相关推荐（列表）。

这时候后端是只给你一个接口好，还是分多个接口去请求好？

从用户的体验来讲，最好先快速加载并渲染出商品信息、优惠信息。其次才是热评、最后是相关推荐。

我个人认为，这种场景真的只用一个接口的话。体验大概率会比较差。分成多个接口，各自加载、渲染可能会更好。那些评论、相关推荐的数据大概率没有商品自己的信息加载来得快。