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

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

NessajCN   
没太懂,你是希望后端专门为你写个接口,把其他接口已经提供的功能和数据整合到这个接口给你,方便你只用请求一次就能获取全部数据?
lithiumii   
@eastjoehan 我遇到过要求能直接写 SQL 查的,这不是完美符合
helone   
你可能刚从业没几年吧,之前我对接的移动端反而觉得后端一个大而全的接口不好,一旦业务或者页面变更,整个接口都要做大变更和重做一个页面没区别,如果分拆开来反而能复用部分之前的代码包括容错的逻辑
qwertyzzz   
@NessajCN 是的吧
fnd   
你们的后端太懒了。就你说的这些情况,需要有一个专门的业务后台来做这些接口的整合,而不是客户端做这些事情。
vincent7245   
这是最基础的架构啊,基础服务 -> 业务代理层 -> 客户端/前端,按照你的描述,是不是你们后端没有做代理层,你直接访问的基础服务的接口?那就自己在客户端做个代理层呗
brader   
>大部分页面通常都要 2-5 个接口。 首先这个现象是正常的,你随便去看哪家大厂的产品,只会调用的更多。
然后从你描述的情况,总结为后端出接口可以有两种方式:1 、按页面来出接口。2 、按功能模块来出接口。
这两种其实都行,都可以实现需求。我个人觉得后端怎么出你怎么用(不合理的接口除外),没有必要非站你角度去强迫对方按哪种方式出接口,只会增加无畏的争吵
zephyru   
这种情况感觉就是,SaaS 中台或者叫业务层与底层服务的区分,后端不想有 UI 的业务代码入侵后端,从设计上考虑其实无可厚非,无非就是 UI 的业务逻辑在哪一层聚合的问题,BFF 层可以后端维护,也可以前端维护,可以写在服务端也可以写在客户端,无关对错只是一个策略问题,你要是有能力可以推进后端针对业务抽象一层出来也不是不行,不好推就自己抽象吧
liumao   
我作为十年老 iOS ,也觉得分开给比较好,我不喜欢一个接口包罗万象。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部