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

[svip0dd]

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

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

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

[rehoni]

@Rehtt #44 问题是接口有顺序需要穿行咋整，比如拿图片 id ，再拿图片 id 去调接口拿图片 url

[x2420390517]

@NessajCN #168 就不管老版本的死活呗，反正新版本没问题就行

[aababc]

@NessajCN 你们这个发版怎么做的，感觉成本很低的样子，感觉我们每次发版都要按周算，最少要要折腾两三天。各个渠道的审核真的够喝一壶的

[lscho]

@bestkayle 讨论问题要就事论事，图片这个毫无疑问是后端的锅。但想一个页面一个接口这个问题毫无疑问是前端的问题。。。。只能说题主的后端同事是在正确的方向做了错的事，题主是在错的方向找到了一个有利于自己描述的例子而已

[iugo]

我们要求的是 "业务原子性", 肯定要涉及到业务.

但那个图片例子, 我觉得是符合业务原子性的. 并且在整体上也不一定会增加调用量, 因为 ID 对应图片地址是可以缓存的, 而不是每次都要, 所以在 App 中可以有一个 map 进行对应.

App 中也可以有一个组件, 不传入 URL, 而是传入图片 ID, 这样前端在做 UI 渲染的时候也可以比较方便.

[macaodoll]

这没什么好吐槽的，后端这么做也没错，难不成你指望一个接口返回全部？

[KAreina]

就事论事的讲。
1. 一个页面要 2-5 个接口是正常的。
2. 不可能有人建一个表只存图片 ID ，再一个存 id 和链接的表，大概率是你理解的有问题，应该是图片 ID 作为外键在其他表里。

[KAreina]

你要是因为这两个问题去挑战后端，大概率被你的前端 leader+后端 leader 双重打脸。

[haichao0808]

你就问他面包房是不是也是把面粉，水，奶油往柜台上一摆就开卖了，顾客要什么类型的面包自己买回去自己做。

[yc8332]

是你们后端垃圾吧，正常数据就要封装好。就你说的图片的问题，他就应该封装好，而不是请求多次。

[a814109257a]

图片的例子，确实不应该这样做，应该简化的，其他的接口真不好说

[wengyanbin]

图片问题，确实是后端的问题。但四个模块要一个接口，个人感觉不合适。这种页面产品不知道后期会迭代多少次，写的太死，前后端都累。后面要是产品发疯，要其中一个模块放到其他页面，那前端的工作量是有了，接口的延迟也就上去了。

[qinfengge]

@jjx #55 仅从灵活性上我也觉得 4 个接口比 1 个好

[xjngbla]

@lambdaq #4 笑死

[NessajCN]

@aababc
就改完了 appcenter codepush release-react 推出去呗....
现代项目在工具链部署完善的情况下 workflow 肯定都已经完善到牙齿了呀
其他框架么肯定也有自己的工具链

[Gilfoyle26]

客户端最适合用 graphql 了，可惜很多后端不会。。。。。。。