原因：App 开发的时候，首页有 4 个相同的模块，在了解到数据是同一个服务提供的，所以希望后端在提供接口的时候能够一次将这个这四个模块的数据整体返回给我。
结论：服务端的大佬说为了保证接口的原子性，不要做太多业务上的事，他们会开发一个通用的接口，有几个模块让我调用几次。其次服务端考虑到后面可能其他的服务也会调用，所以希望能尽可能通用。
以上结论在前后端对接时他们时常用这个说法对我进行 pua ，我觉得我已经无法接受了，请问各位大佬，这种情况如何反驳？为了保证他们接口的原子性，我大部分页面通常都要 2-5 个接口，甚至更多，比如之前获取图片，因为他们的图片是两张表，一张是图片 id ，一张是 id 对应的图片地址。我只能先获取 id ，再用 id 去请求接口。但服务的通用性在这个说法我在长期对接中发现纯属扯淡，几乎只有我在对接且因为接口调用的多了增加各种复杂场景，如果没有处理好也会影响用户体验。
闽公网安备 35020302035485号
你对接的后端做着业务后端的工作，但用着基础服务的心态提供接口。同意前面大佬所说的，提供一层聚合层/业务后端层来解决这个问题。我觉得客户端使用的接口就要提供视图所要求的数据，试想一下如果产品以 api 接口提供对外服务，提供这样的 api 能力，感觉客户得把你骂死。自己人折磨自己人也是很正常，这些 dirtyworks 谁都不想做，但总是要做，就看公司内部话语权了。
「服务端考虑到后面可能其他的服务也会调用，所以希望能尽可能通用」这句话看起来也没有问题，保证接口的单一职责的确很重要，但归根到底，这是接口开发者的职责，不是接口使用者的义务；
如果「单个接口返回需要的多个数据」需求是成立，那么接口怎么实现以及将来怎么复用是后端需要考虑的问题，后端只要提供这个接口就好，不能教对接方做事吧；
但是「单个接口返回需要的多个数据」是否真的成立，比如不在一个接口返回，非常难渲染界面；
如果仅仅是因为「数据是同一个服务提供的」就希望「一次将这个这四个模块的数据整体返回」在我看来这是不够具有说服性的——这相当于将前端组合接口的工作转移到了后端（属于“损人利己”），所以后端需要拒绝，然后就找了一些通用啊、复用啊这类的“说辞”（虽然也有道理）
至于 pua ，九字真言呗；
吐槽归吐槽，还是要解决问题：给后端一个不能拒绝的理由很重要；如果只是针对某一个人，为了维护自己的利益，那么引入第三方——各自的 leader 或者资深程序猿，也是一个方法；