一个查询周数据的需要,实际用户只在昨天产生了行为数据。前端侧说为了通用性,要求接口补齐一整周的数据,并按照 72460 ,每分钟都要数据记录,这样前端根据时间点来绘图,这种要求合理吗? 大家遇到这种场景时是怎么定义接口测规范的?
1
wxw752 155 天前 2
我们公司后端强一些,数据都在后端处理的。前端都是年轻人,对着 UI 画样式就可以了,数据往页面一丢 不用过脑子
|
2
x66 155 天前 1
不合理,
如果没有特殊业务逻辑的补全,前端也可以做,后端补了只会让 response 变大,不管是从经济上讲还是从 api 性能上讲都没有好处。 而且服务端的资源要钱,而浏览器的计算资源不需要我们付费 |
3
huifer 155 天前
没有数据就应该没提供,和 json 是否要将 null 的数据返回这个字段一样.
|
4
hxtheone 155 天前 via iPhone 1
个人看法, 谁对空值有业务需求谁来处理, 试想一下, 如果这个接口有两个调用方, 为了一个调用方补齐了数据, 那对另一个调用方来说, 它怎么知道这个数据是真实的还是后端补的
|
5
sampeng 155 天前
你问别人没用。。这种事没有什么绝对对错。谁吵得过谁就是对的
|
6
windmoonwind 155 天前
@hxtheone 领导偏心的话,会让你再多做个接口,专用于输出美化修补后数据🤣
|
7
snowonion 155 天前
1. 谁补:
这里补的数据没有信息量,理论上前后端都可以干,就是谁多干点谁少干点的分工问题。然后接口的 spec 要跟着变。 理想世界:“工友,我的前端代码(我用的轮子)不够鲁棒,处理不了数据点没塞满的情况,你能帮忙处理吗?” 楼主情况:“为了通用性” 2. 假如后端补,注意约定如何区分零值( 0 、空串)/ 没有值。这也可以应对 4# 的顾虑。 3. 性能方面,数据越稀疏,后端补越不合理。(啊楼主说的是往前补齐数据;不知道在开始有数据之后值为 0 的时间点你们怎么处理) |
8
senl 155 天前
不合理吧,处理肯定是前端处理的,前后端可以约定 null 值都是默认不传的,约定好默认布空就好了
|
9
flytsuki 155 天前
前端去补。但是前后端都是我写的话,哪边方便哪边处理
|
10
shuxhan 155 天前
一看到这,我真特么想吐槽我们公司后端,字段空值就不能统一掉,啥又有,null, 0, "", [],等等等等,直接给 res 设为 data: null ,没有任何统一风格可言,字段名称 小写大写驼峰下划线混着用,甚至获取和提交的接口,明明是同一个东西,字段名都不一样
|
11
IvanLi127 155 天前
接口名称就是说查一周的数据,那需要补全。当然如果叫查询某日到某日的数据就不需要你补了。
传输的数据量变大了那这个和接口在设计上是否补全数据无关,和传输的协议没做压缩有关,如果一开始没考虑到压缩问题,那只能商量看怎么办。要是因为被压缩了导致前端说数据不全,那就是前端实现问题了。 理论上前端需要对收到的数据重新反序列化,但是如果你的后端只为这个前端应用服务,那反序列化的部分可能会算在你这,在这个情况下你没得选,只能听前端的。否则以后端为准。 |
12
xiangbohua 155 天前 via iPhone
我觉得要看接口定义了,业务接口肯定要符合接口设计的含义,数据接口的话可能看展示方式吧,我还是倾向于补全
|
14
NessajCN 155 天前
屁大点事.....两行代码的问题也值得拿出来说
前端是不会用 if 吗 |
15
JoJoWuBeHumble 155 天前
@shuxhan 你这个是管理的问题了
|
16
Sawyerhou 155 天前
正常来讲不应该,接口只提供数据,不负责计算,补数据属于计算了,如果接口提供补数据功能,就会出现有人希望最新填充,有人希望均值填充,有人希望 0 填充,有人希望字符填充......那接口就乱套了。
|
19
neptuno 155 天前
后端返回太多无用的数据,用户量大了,都是流量,都是公司的钱,看你怎么把这个意思跟领导、前端解释了。
|
20
shadowyue 155 天前
本质上是你们产品出需求没说清楚,显示最近一周的图表,如果数据不够一周怎么办。
先让产品出方案。 技术上说,我是前端,不过我觉得两边谁处理都行都行,无非工作量的问题。 你和前端沟通不下来,找领导拍板就行。 |
21
lqm 155 天前
我是前端,这个问题得产品明确需求。
1 ,如果你补 0 了,那么前端出图(假设 echarts )是连续线段,如果你没有补 0 ,前端出图是断断续续的 2 ,横坐标数据列表需要前端自己计算出来 我遇到过更恶心的场景,产品需求横坐标步长是动态的,但是后端出的数是不连续的,前端需要从后端不连续的数据自己推断步长。 |