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

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

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

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

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

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

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

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

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

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

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

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

@dcdlove 那我就要说凭什么满足你前端了 数据是我从数据库拿的 你前端这么牛逼 你也去从数据库捞去吧 反正接口我给了 你爱用不用

领域层提供原子服务接口，应用层提供业务编排接口。

如果他是一个项目里直接从 HTTP API 干到数据库，我的建议是直接跑路

如果后端不是响应式的话，后端聚合会不会还慢一点？
因为服务端做并发查询还需要额外写代码，但前端并发请求过来的话一般都分配到不同线程上处理了