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

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

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

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

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

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

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

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

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

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

问就是 graphQL

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

如果是两组数据。

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


具体情况具体分析吧。




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



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


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

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

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

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

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

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

看团队 leader 的话语权了。

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