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

[chenxiaolani]

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

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

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

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

[Peachl]

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

[zu1y]

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

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

[samnya]

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

[dayeye2006199]

问就是 graphQL

[sunchuo]

如果是一个数据的各种枚举的中文映射的场景。是后端不讲理，建议后端按照约定的 schema 一次返回。

如果是两组数据。

如果有多个前端（不是程序员，是客户端），应该更倾向于听后端的。因为不是专门伺候你。
如果仅一个前端，可以以前端开发为主（后端开发是生产者，前端开发是消费者），谁离业务更近，谁说了算，谁责任大。别说帮忙合并数据面向页面提供接口，前端要求后端直接返回渲染好的 html 都行。
但具体实践中大部分要看习惯和交情。


具体情况具体分析吧。




从 op 描述来看。
op 更想省事，后端理由正当合理。



我们要判断争论点是把复杂度和锅（我可以听你的这么做，但是出问题你负责）从谁转移到谁。
争夺复杂度和锅的争论，推脱复杂度但是不甩锅的争论，大部分都是好同志。
推脱复杂度同时也不背锅的争论，我们可以直接理解为队伍里出现了不合适的人。


另外多说一句：
技术团队的技术争论，
如果有人不「站在 “整体”的位置上，看“现在”和“将来”，」
还争个热火朝天，
如果不是公司薪资水平不行。那要么是菜，要么是坏。

[KING754]

也不一定,非要怎么样吧.

具体不知道是一个什么样表格.

不过,就订单或者商品信息.
如果订单信息,一开始只展示粗略信息.(就是一开始,并不会显示所有商品,而是用户点一个详情,然后再显示)
这种情况,我肯定是拒绝一下子,全部返给前端.

其它情况,要商量着看吧.

[8355]

app 或者大模块首页接口之类的必要性大模块结构可以提供聚合，其他的接口最多提供多批量查询。
接口性能和可靠性是后端负责的话就不可能给你这么提供，不然前后端分离意义在哪不如直接 display ？

[pxllong]

看团队 leader 的话语权了。

[MoYi123]

感觉很多前端都会莫名其妙地追求性能, 前端代码跑在用户的设备上, 成本也不用公司出, 接口慢了也不用前端背锅, 为什么老是要用性能为理由来要求后端改接口呢?

[LitterGopher]

作为后端，如果你要是问我是不是一定要保持单一原则，那我会毫不犹豫的说：是。

但我会依据情况不同改变对单一原则的认定标准（底线灵活）。

[SolaWing]

单一职责是给内部代码维护用的，不是给外部直接调用的。单一职责的优势是可组合性非常强，代码好维护。但是如果这个接口被外部用了，以后想变就没那么容易了。给外部使用的接口应该首先保证可控，其次才考虑扩展性和灵活性。如果针对外部使用场景专门封装了场景特化接口，这个接口可以随时根据场景调整，内部的单一接口也可以随时按需重构，内部代码的可控性和外部边界都会清晰很多。

[gerefoxing]

视具体业务情况而定

[siweipancc]

我只会给你开一个聚合接口，不保证后续兼容

[9pr7im4IjQ9u0806]

看数据的关联性，如果是相对隔离的数据，就分开，不然其他页面正好需要其中一个接口的数据呢，接口单一职责原则的好处不是仅仅对于这一个页面来说的，而已整个系统，职责单一的接口可以灵活的支持其他业务的需求，大接口，基本上只能满足你这一个需求。其他需求要用的话，返回的无用字段太多了。单独一次请求的性能并不一定比两次性能好或者说有感知的提升啊，都是异步并发调用，而且大多时候，观感上来说，分多个接口的效果反而更好（数据逐步渲染，但人眼看到有部分数据出来，就会觉得已经响应了）

[MYlyc]

组里领导，前端出生，写喂饭式接口