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

[svip0dd]

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

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

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

[bigfei]

自己建立个 BFF 层，扩大代码的 ownership ，防御性编程。

[Gil86002618]

写个 BFF 层处理吧，其实服务端说的也没错，有些服务就是基础服务，跟具体的业务无关，需要考虑接口的通用性。

[hging]

你想想如果明天产品跟你说 要再加一个数据 那你是让后端给你加接口方便还是用通用的自己接方便。

[lambdaq]

接口原子性最后的进化就是客户端直连 sql 。

[woodfizky]

设计上应该保持各个方法/接口的原子性，但是给到前端的接口可以根据业务具体情况让后端自己整合一下。
当然也可以不整合。

但是图片分两张表/两个接口有点奇怪，两张表不是可以联表查出来一起给到前端嘛，反正都是 url ，又不会有多大。

我只能说你举的例子不够明确具体，最好给个例子。

[unco020511]

可以自己加个中间层处理下,对于你的业务还是调一个接口

[vacuitym]

其实分开比较好，你想一下四个模块有一个出问题了，你希望是只有三个模块数据正常展示还是说四个数据全部无法展示

[FEontheway]

让后端再另外提供一个聚合接口调这个通用服务不就行了。而且多个接口同时调用，各个模块展示顺序也不好控制，不会影响用户体验吗

[lzgshsj]

为什么要反驳？用着不爽就自己弄 BFF 。另外这种事情不应该让你们的 leader 定调吗

[JoeDH]

我前司的领导在搞部门的业务中台需求评审时说，想把中台服务搞成只有一个接口，要兼顾所有数据，还要兼顾对外开放的格式

[NessajCN]

没太懂，你是希望后端专门为你写个接口，把其他接口已经提供的功能和数据整合到这个接口给你，方便你只用请求一次就能获取全部数据?

[lithiumii]

@eastjoehan 我遇到过要求能直接写 SQL 查的，这不是完美符合

[helone]

你可能刚从业没几年吧，之前我对接的移动端反而觉得后端一个大而全的接口不好，一旦业务或者页面变更，整个接口都要做大变更和重做一个页面没区别，如果分拆开来反而能复用部分之前的代码包括容错的逻辑

[asLw0P981N0M0TCC]

@NessajCN 是的吧

[fnd]

你们的后端太懒了。就你说的这些情况，需要有一个专门的业务后台来做这些接口的整合，而不是客户端做这些事情。

[vincent7245]

这是最基础的架构啊，基础服务 -> 业务代理层 -> 客户端/前端，按照你的描述，是不是你们后端没有做代理层，你直接访问的基础服务的接口？那就自己在客户端做个代理层呗

[brader]

>大部分页面通常都要 2-5 个接口。 首先这个现象是正常的，你随便去看哪家大厂的产品，只会调用的更多。

然后从你描述的情况，总结为后端出接口可以有两种方式：1 、按页面来出接口。2 、按功能模块来出接口。
这两种其实都行，都可以实现需求。我个人觉得后端怎么出你怎么用（不合理的接口除外），没有必要非站你角度去强迫对方按哪种方式出接口，只会增加无畏的争吵

[zephyru]

这种情况感觉就是，SaaS 中台或者叫业务层与底层服务的区分，后端不想有 UI 的业务代码入侵后端，从设计上考虑其实无可厚非，无非就是 UI 的业务逻辑在哪一层聚合的问题，BFF 层可以后端维护，也可以前端维护，可以写在服务端也可以写在客户端，无关对错只是一个策略问题，你要是有能力可以推进后端针对业务抽象一层出来也不是不行，不好推就自己抽象吧

[ilovegaojianfore]

我作为十年老 iOS ，也觉得分开给比较好，我不喜欢一个接口包罗万象。

[liumao]

这图片表为啥要分开存，啥呆逼设计