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

2024-04-29 09:58:45 +08:00
svip0dd  svip0dd
原因:App 开发的时候,首页有 4 个相同的模块,在了解到数据是同一个服务提供的,所以希望后端在提供接口的时候能够一次将这个这四个模块的数据整体返回给我。

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

以上结论在前后端对接时他们时常用这个说法对我进行 pua ,我觉得我已经无法接受了,请问各位大佬,这种情况如何反驳?为了保证他们接口的原子性,我大部分页面通常都要 2-5 个接口,甚至更多,比如之前获取图片,因为他们的图片是两张表,一张是图片 id ,一张是 id 对应的图片地址。我只能先获取 id ,再用 id 去请求接口。但服务的通用性在这个说法我在长期对接中发现纯属扯淡,几乎只有我在对接且因为接口调用的多了增加各种复杂场景,如果没有处理好也会影响用户体验。
23732 次点击
所在节点   程序员  程序员
216 条回复
xFrye
xFrye
2024-04-29 10:20:41 +08:00
我反过来了,非常不喜欢一个接口给我返回所有的数据
MoYi123
MoYi123
2024-04-29 10:20:54 +08:00
专门为你的页面写个接口是没道理的.
可以让后端提供一个能一次性查询多个接口的方法.
大概下面那样.
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"}]}
MillaMaxwell
MillaMaxwell
2024-04-29 10:24:49 +08:00
后端,这种并不是 pua,全部丢一个接口里只会增加维护的麻烦程度
lsk569937453
lsk569937453
2024-04-29 10:27:37 +08:00
去哪儿的 app 首页有二十多个接口。
aino
aino
2024-04-29 10:28:29 +08:00
后端给你什么就接着就对了
angenin
angenin
2024-04-29 10:29:18 +08:00
@liumao 我觉得应该是,有一张专门的图片表,而其他表的图片字段(例如用户表头像)只存图片 id ,前端需要通过图片 id ,调一个图片接口获取图片的实际路径,再获取到图片。(我们之前的项目,领导就是这么设计的)

另外,关于接口方面,可以两种都兼容,基础服务的接口也提供,如果某个页面需要调用的接口太多了(比如十几个?),可以要求后端再单独提供个大接口,前端第一次调用调大接口,局部刷新也能用基础服务接口。

当然可以跟 leader 反馈下,看领导安排。
Philippa
Philippa
2024-04-29 10:29:45 +08:00
你说的实际例子,要先获取 id 和然后跟据 id 取请求接口这个做法非常普遍。
后端不需要关心展示逻辑,而是关心数据逻辑。高度集成的接口其实把展示逻辑也丢给了后端,进行变动时需要前后端同时处理,所以前后端的确需要分离数据逻辑和展示逻辑。

很多前端都想一个 API 获取所有数据,巴不得镶嵌结构也刚好是页面的结构,但那样就耦合了业务逻辑和数据逻辑了。但这个是不可能的,你看看 GraphQL 一个 API 的结果就是前端还要熟悉表结构……
uiosun
uiosun
2024-04-29 10:30:40 +08:00
保持原子性不是提供 SQL 让前端自己查——接口层面的原子性是后端不写重复的 [业务接口] 。

你们后端直接一步干到“后端不写业务接口”了,那还要后端干嘛,直接 GraphQL API 给前端,后端转岗前端完事了。
8355
8355
2024-04-29 10:31:21 +08:00
可能确实是你认知问题。。
app 本身是需要兼容老版本的,你一个接口返回太多东西以后怎么兼容,后端做版本判断?
dr1q65MfKFKHnJr6
dr1q65MfKFKHnJr6
2024-04-29 10:31:53 +08:00
一个耗时 200ms 的接口 包含所有,
4 个每次耗时 20ms 的接口 , 你怎么选??
除了前端外, 后端、leader 基本都会选后者
liumao
liumao
2024-04-29 10:32:54 +08:00
@angenin 是我就直接在业务表里面存路径了,还存个 p 的 id
NessajCN
NessajCN
2024-04-29 10:33:10 +08:00
@qwertyzzz 你看,你也同意是「已经提供的数据」。那你自己整合一下呗。前端写肯定比后端写简单啊。毕竟前端弄不崩服务器,后端可以。
htxy1985
htxy1985
2024-04-29 10:33:34 +08:00
图片分成两个表是为什么? id 和 url 的关系还留着扩展成一对多,多对多的可能?
BiChengfei
BiChengfei
2024-04-29 10:33:39 +08:00
你是客户端,他是服务端,大致属于 B/S 模式,服务端皆苦应该符合外观模式,对客户端隐藏系统的复杂度。应该针对不同的客户端封装不同的接口
lazyfighter
lazyfighter
2024-04-29 10:37:33 +08:00
需要一个聚合层, 面向 C 端的一般都不是原子性的接口, 聚合服务支持业务逻辑面向不同端的定制, 此时你只需要反驳一句,如果 web 跟小程序逻辑不一样,那你后端接口是否还是原子性的, 原子性没有问题但是更多的是面向自己的服务领域做到高内聚低耦合,当真正的面向 C 端业务场景的时候,我们应该做的是聚合多个原子能力,对外输出业务场景能力。
angenin
angenin
2024-04-29 10:40:01 +08:00
@htxy1985 对,有可能是一对多,如果金融行业,用户的实名认证信息,过期了要补充新的,但不能删除以往的图片,在图片表里记录用户 id 和图片类型,必要时可以查出所有以往的材料,也不叫图片表应该叫文件表。
dongtingyue
2024-04-29 10:42:25 +08:00
图片那个例子不合理吧,原子性不是这样定义的。
一个请求变两个请求,前端并发量也成备。
angenin
2024-04-29 10:42:57 +08:00
@liumao #31 如果文件不能删,并且必要时需要查出用户以往上传过的文件,阁下应该如何处理
wangritian
2024-04-29 10:43:08 +08:00
后端这样设计是合理的,上面有提到 BFF 层,还可以在前端封装一个并发请求,合并拿返回数据的通用方法
这要求后端需要支持 h2 协议,必须支持
asLw0P981N0M0TCC
2024-04-29 10:43:13 +08:00
@NessajCN #32 啊 我不试楼主 不过后端更方便吧。。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1036619

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX