后端传过来的某些属性不固定，有时候有，有时候没有，这样合理吗？

[darknoll]

比如和后端商定好了，返回的接口格式是： { "A": "", "B": [{}, {}] } 这时候后端说了，B 的数据有时候没有，如果没有的话就直接返回{A:""} 我让他返回{"A"："***", "B":[]}

哪种方案好？

[shoushi]

json 转的时候可以配置 null 值是否删除字段吧

[jheroy]

内部使用的接口直接私有协议，自己写协议文件，或者用 protobuf，这样不但性能好，还省流量。 公开协议才用 json，兼容性高，如果是公开协议了，文档肯定得写好。

[keepeye]

前端定义个默认 json，object.assign 一下即可吧。后端可能是个动态语言，如果是结构体序列化的应该是有字段的

[keepeye]

@Rhonin 我看淘宝接口很多这样的字段不固定，他们应该有测试吧

[fansfans]

@Rhonin 这种数据格式前端处理起来比后端更方便 特别是对于#14 所说的情况

[Sparetire]

类型的角度来讲显然第二种好，第二种的类型始终是数组，处理起来更加一致。第二种情况极端情况下一个接口几十个字段一半都在判空，漏一个出了 bug 就想骂人，而那一大坨判空操作在语法糖的帮助下看起来都显得臭不可闻，没想到本站这么多人喜欢 null 这种糟粕。。
突然觉得每个后端都应该把接口用 json schema 滤一遍，bug 从源头消灭掉

[trlove]

@Rhonin 我不知道你有没有看别人网站接口的习惯，就我观察来看，很多大厂都是第一种情况，没有字段都不返回。就比如 msg data 两个参数来说，很多大厂都是如果接口返回错误信息 那就只返回 msg 字段 看不到 data 字段了，如果业务正常返回数据 那 msg 就没了 只有 data 。而且 data 通常都是动态的，有时候可能是单条数据 有时候可能是单字符 有时候可能是数组，按第二种方式来，如果 data 为空，没数据的时候，那这个 data 是给它赋值空字符 还是空数组？还是给它 null?其次有些字段用不到的返回有什么意义呢，显得 json 长吗？而且一般这种处理都是后端通用处理方式，不会是每个接口单独去处理到底该返回空字符还是 null 还是空数组问题，单个接口都来一遍，碰到字段多的，嵌套多的，得写多少个循环多少个 if……

[znyq2019]

两边都做 . 别想着省事

[zeropercenthappy]

作为一个移动端开发，我支持第一种，数据看起来舒服，处理起来也不需要太多额外的操作。
可以省略，但是不能变。
如果一会儿是"B":[]，一会儿是"B":""，那我就要喷人了。

[laminux29]

必然第二种方案，因为人都会犯错，第一种方案无法区分到底是 B 不存在，还是前端忘了回发 B 的值。

另外：B 不存在、B 存在但为空、B 存在不为空但为空数组等等，这些都是不同的逻辑。建议增加状态字段来区分这些情况。

比如前端应该这样返回：

struct ResultData
{
....string A;

....//Bstate：B 的状态码
....// 0:B 不存在； 1:B 存在但为 null ； 2:B 存在且有值。
....byte Bstate;

....//当 Bstate 为 2 时，允许 B 为空数组。
....array B;
.
}

[guanhui07]

第二种

[trlove]

@laminux29 加状态字段……然后一个接口 100 字段，外加 100 个状态字段，然后还得根据状态字段去决定是否渲染值…… 那为何不直接 if 字段 然后渲染…… 至于说的无法区分到底是 B 不存在还是前端忘了回发 B 的值，对于第二种，如果这个错误能犯，那你家状态字段，也可能会犯不判断状态的错误……这种问题就是自己的 bug 。对于第一种，只要你前端判断没有这个字段，至于后台是真有还是真没有，那是后端的事，出问题也是后端吧锅端着

[cco]

你的逻辑需要都有，那么是空值那就得都有，你的逻辑有判断，那就没啥毛病。

[Paladinfeng]

数组为空最好给个空数组，要不前端用起来不好用

[IvanLi127]

第二种方案好，合理。第一种方案为了性能？为了性能为什么还用 json ？就是懒！

[AoEiuV020]

我也觉得数据类型必需统一，有数据是数组，那没数据当然就是空数组了，你敢给 null 我就敢崩溃，

[koolob]

第一种呀。要知道出流量可都是钱呀。

[gzf6]

data?.B

[galikeoy]

这个站还是后端多啊，s 逼数据结构，后面接手的人一脸懵逼
@Rhonin #33

[ashmodeus]

最好自己写兼容逻辑，凡是提前协商的在真正出线上问题时，都有可能变成甩锅的情况。