数据不全需要在接口侧补全吗

我们公司后端强一些，数据都在后端处理的。前端都是年轻人，对着 UI 画样式就可以了，数据往页面一丢 不用过脑子

不合理，
如果没有特殊业务逻辑的补全，前端也可以做，后端补了只会让 response 变大，不管是从经济上讲还是从 api 性能上讲都没有好处。
而且服务端的资源要钱，而浏览器的计算资源不需要我们付费

没有数据就应该没提供，和 json 是否要将 null 的数据返回这个字段一样.

个人看法, 谁对空值有业务需求谁来处理, 试想一下, 如果这个接口有两个调用方, 为了一个调用方补齐了数据, 那对另一个调用方来说, 它怎么知道这个数据是真实的还是后端补的

你问别人没用。。这种事没有什么绝对对错。谁吵得过谁就是对的

@hxtheone 领导偏心的话，会让你再多做个接口，专用于输出美化修补后数据

1. 谁补：
这里补的数据没有信息量，理论上前后端都可以干，就是谁多干点谁少干点的分工问题。然后接口的 spec 要跟着变。
理想世界：“工友，我的前端代码（我用的轮子）不够鲁棒，处理不了数据点没塞满的情况，你能帮忙处理吗？”
楼主情况：“为了通用性”

2. 假如后端补，注意约定如何区分零值（ 0 、空串）/ 没有值。这也可以应对 4# 的顾虑。

3. 性能方面，数据越稀疏，后端补越不合理。（啊楼主说的是往前补齐数据；不知道在开始有数据之后值为 0 的时间点你们怎么处理）

不合理吧，处理肯定是前端处理的，前后端可以约定 null 值都是默认不传的，约定好默认布空就好了

前端去补。但是前后端都是我写的话，哪边方便哪边处理

一看到这，我真特么想吐槽我们公司后端，字段空值就不能统一掉，啥又有，null, 0, "", [],等等等等，直接给 res 设为 data: null ，没有任何统一风格可言，字段名称 小写大写驼峰下划线混着用，甚至获取和提交的接口，明明是同一个东西，字段名都不一样

接口名称就是说查一周的数据，那需要补全。当然如果叫查询某日到某日的数据就不需要你补了。

传输的数据量变大了那这个和接口在设计上是否补全数据无关，和传输的协议没做压缩有关，如果一开始没考虑到压缩问题，那只能商量看怎么办。要是因为被压缩了导致前端说数据不全，那就是前端实现问题了。

理论上前端需要对收到的数据重新反序列化，但是如果你的后端只为这个前端应用服务，那反序列化的部分可能会算在你这，在这个情况下你没得选，只能听前端的。否则以后端为准。

我觉得要看接口定义了，业务接口肯定要符合接口设计的含义，数据接口的话可能看展示方式吧，我还是倾向于补全

@IvanLi127 数据量大，直接 protobuf ， 连续相同的数据压缩比很大。

屁大点事.....两行代码的问题也值得拿出来说
前端是不会用 if 吗

@shuxhan 你这个是管理的问题了

正常来讲不应该，接口只提供数据，不负责计算，补数据属于计算了，如果接口提供补数据功能，就会出现有人希望最新填充，有人希望均值填充，有人希望 0 填充，有人希望字符填充......那接口就乱套了。

@Sawyerhou 不过如果填充格式可以定死的话，也不是完全不可接受。

@shuxhan null =0 吗？前端还是前端啊

后端返回太多无用的数据，用户量大了，都是流量，都是公司的钱，看你怎么把这个意思跟领导、前端解释了。

本质上是你们产品出需求没说清楚，显示最近一周的图表，如果数据不够一周怎么办。
先让产品出方案。

技术上说，我是前端，不过我觉得两边谁处理都行都行，无非工作量的问题。
你和前端沟通不下来，找领导拍板就行。

我是前端，这个问题得产品明确需求。
1 ，如果你补 0 了，那么前端出图（假设 echarts ）是连续线段，如果你没有补 0 ，前端出图是断断续续的
2 ，横坐标数据列表需要前端自己计算出来

我遇到过更恶心的场景，产品需求横坐标步长是动态的，但是后端出的数是不连续的，前端需要从后端不连续的数据自己推断步长。