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

查看 467|回复 48
xFrye   
这图片表为啥要分开存,啥呆逼设计
MoYi123   
我反过来了,非常不喜欢一个接口给我返回所有的数据
MillaMaxwell   
专门为你的页面写个接口是没道理的.
可以让后端提供一个能一次性查询多个接口的方法.
大概下面那样.
req
{"data": [{"uri": "get_user", "body": {}}, {"uri": "get_time", "body"}]}
resp
{"data": [{"uri": "get_user", "resp": {"id": "12313"}}, {"uri": "get_time", "resp": "2024-4-29"}]}
lsk569937453   
后端,这种并不是 pua,全部丢一个接口里只会增加维护的麻烦程度
aino   
去哪儿的 app 首页有二十多个接口。
angenin   
后端给你什么就接着就对了
Philippa   
@liumao 我觉得应该是,有一张专门的图片表,而其他表的图片字段(例如用户表头像)只存图片 id ,前端需要通过图片 id ,调一个图片接口获取图片的实际路径,再获取到图片。(我们之前的项目,领导就是这么设计的)
另外,关于接口方面,可以两种都兼容,基础服务的接口也提供,如果某个页面需要调用的接口太多了(比如十几个?),可以要求后端再单独提供个大接口,前端第一次调用调大接口,局部刷新也能用基础服务接口。
当然可以跟 leader 反馈下,看领导安排。
uiosun   
你说的实际例子,要先获取 id 和然后跟据 id 取请求接口这个做法非常普遍。
后端不需要关心展示逻辑,而是关心数据逻辑。高度集成的接口其实把展示逻辑也丢给了后端,进行变动时需要前后端同时处理,所以前后端的确需要分离数据逻辑和展示逻辑。
很多前端都想一个 API 获取所有数据,巴不得镶嵌结构也刚好是页面的结构,但那样就耦合了业务逻辑和数据逻辑了。但这个是不可能的,你看看 GraphQL 一个 API 的结果就是前端还要熟悉表结构……
8355   
保持原子性不是提供 SQL 让前端自己查——接口层面的原子性是后端不写重复的 [业务接口] 。
你们后端直接一步干到“后端不写业务接口”了,那还要后端干嘛,直接 GraphQL API 给前端,后端转岗前端完事了。
cedoo22   
可能确实是你认知问题。。
app 本身是需要兼容老版本的,你一个接口返回太多东西以后怎么兼容,后端做版本判断?
您需要登录后才可以回帖 登录 | 立即注册

返回顶部