对接后端接口被挑战能力不行（吐槽贴，不会因为这个问题去挑战什么）

[svip0dd]

原因：App 开发的时候，首页有 4 个相同的模块，在了解到数据是同一个服务提供的，所以希望后端在提供接口的时候能够一次将这个这四个模块的数据整体返回给我。

结论：服务端的大佬说为了保证接口的原子性，不要做太多业务上的事，他们会开发一个通用的接口，有几个模块让我调用几次。其次服务端考虑到后面可能其他的服务也会调用，所以希望能尽可能通用。

以上结论在前后端对接时他们时常用这个说法对我进行 pua ，我觉得我已经无法接受了，请问各位大佬，这种情况如何反驳？为了保证他们接口的原子性，我大部分页面通常都要 2-5 个接口，甚至更多，比如之前获取图片，因为他们的图片是两张表，一张是图片 id ，一张是 id 对应的图片地址。我只能先获取 id ，再用 id 去请求接口。但服务的通用性在这个说法我在长期对接中发现纯属扯淡，几乎只有我在对接且因为接口调用的多了增加各种复杂场景，如果没有处理好也会影响用户体验。

[liumao]

@angenin #38 这需求必然要做一张用户和文件关联表，我业务表里存路径，拿来就用。历史上传记录就是另外的功能了，用关联表就可以了。

[james2013]

这是后端问题多点
我讨厌后端只提供增删改查，而不是根据界面开发接口

[qeqv]

减少精神内耗，把情况和领导/老板反应，权利是自己争取的。如果争取失败了也可以心安理得地接受

[Rehtt]

一个 200ms 包含所有数据的请求和 4 个 50ms 的请求，如果配有负载均衡这 4 个请求可以被均衡掉减小对服务器的压力

[lasuar]

既然你没有太大话语权，那就听后端的吧。职场中没有绝对的技术权力。

[iOCZS]

promise.all[]解君愁

[shengchao]

让后端同一个服务支持类 jsonrpc 那种查询就可以了
由单一 obj 的 json 扩展成数组,例子如下
req:
{"method": "getrawtransaction", params: ["aaa", "bbb", "ccc"]}
=>
[
{"method": "getrawtransaction", params: ["aaa", "bbb", "ccc"]},
{"method": "sendMessage", params: ["aaa", "bbb", "ccc"]},
]

[chengxy]

一个数据列表返回了 10 条数据，每条数据上都有 5 个图片 id ，前端先调取数据接口，渲染的时候再分别调取 5 次图片接口，除非图片接口可以直接返回图片，否则我是接受不了。

[wumou]

我觉得两个人都没错。
问题是层级少了，缺少一个负责聚合数据的中间层。

[aduangduang]

加一层 graphql

[blessingcr]

不懂前端，但是后端这样做合理的
不过可以让后端多提供一个聚合数据的接口

[wangmn]

能跑就行

[12471220]

就是后端懒，所有东西不想动全交给前端处理，还美名其曰原子性

[lwjlol]

人家没毛病，接口设计尽量简洁，不要大而全，至于你想一下子把数据请求全了，可以自己二次加工，在自己的 repo 层合并

[jjx]

后端是对的

后端服务应该可以被组合使用, 这样前端可以获得最大的灵活性和扩展性

否则后端服务就是死的

前端如果认为四个调用在一组,写个函数处理一下不就得了

[sampeng]

说服不了就加入

[Huelse]

那你就不优化了，按他们的要求写，只要有一个接口慢了出现卡顿就怪他们头上去

[levintrueno]

@helone A 站肥肥？

[rxswift]

一个页面 5 个接口很正常

[NilXuan]

我是写后端的；
「服务端考虑到后面可能其他的服务也会调用，所以希望能尽可能通用」这句话看起来也没有问题，保证接口的单一职责的确很重要，但归根到底，这是接口开发者的职责，不是接口使用者的义务；
如果「单个接口返回需要的多个数据」需求是成立，那么接口怎么实现以及将来怎么复用是后端需要考虑的问题，后端只要提供这个接口就好，不能教对接方做事吧；
但是「单个接口返回需要的多个数据」是否真的成立，比如不在一个接口返回，非常难渲染界面；
如果仅仅是因为「数据是同一个服务提供的」就希望「一次将这个这四个模块的数据整体返回」在我看来这是不够具有说服性的——这相当于将前端组合接口的工作转移到了后端（属于“损人利己”），所以后端需要拒绝，然后就找了一些通用啊、复用啊这类的“说辞”（虽然也有道理）
至于 pua ，九字真言呗；
吐槽归吐槽，还是要解决问题：给后端一个不能拒绝的理由很重要；如果只是针对某一个人，为了维护自己的利益，那么引入第三方——各自的 leader 或者资深程序猿，也是一个方法；