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

[darknoll]

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

哪种方案好？

[tsanie]

第一种第二种都行，但是就算是第二种方案，前端最好也要做一下 B 没有的容错吧

[wangyzj]

为空也得返回，减少 confuse

[lrh3321]

都合理，互相不信任防御性编程，到时候不容易出错

[whileFalse]

首先，前端能有多难处理一个不存在的属性？
其次，要说合理的话还是要具体分析。有的业务情况下，不存在和存在一个空数组是不同的状态，需要分别处理的。

[mmdsun]

对象空可以返回 null
数组空建议是返回空 []

[john6lq]

说返回 null 合理的不怪你写一辈子烂代码。

[netnr]

不合理

[xianxiaobo]

肯定是第二种啊，第一种容易出问题，必须让后端改成第二种，不然离职。

[guisheng]

如果没有接口文档建议写第二种，如果有我建议使用第一种。

[ebony0319]

我猜其实后端也一脸懵逼.序列化框架做的.第一种目前也存在,只是用的少了而已.

[GoodKvm]

第二种

[p1gd0g]

用 protobuf 吧。。。

[ramcasky]

@whileFalse 业务复杂还挺难处理的

[weixiangzhe]

主要是 null 前端不是很好处理，建议 request 那里处理一下，为 null 改为 undefined

[roudancongji]

盲猜一手用的 mongodb ？

[lagoon]

有多少公司能很好的维护更新文档的？
反正我见过许多老项目，最终都是要看代码来理解的。

{A:""}，以后想要知道这接口只返回 A，还是可能会有 B，就比较麻烦了。特别是一些不怎么出现的参数。
接口按结构返回了，以后调一遍，看看结构，理解当时的接口情况简单多了。

[EminemW]

怎么可能返回 null……真有人这么写？

[yaphets666]

觉得第一种好的,不论你干了多少年,源码多熟算法多牛逼,你的同事一定讨厌你.

[luhuisicnu]

看场景吧，非必要的可选字段，前端检查到就展示，未检查到就不做处理，如果是必须字段，那么必须要返回 key，value 看场景给出

[sonxzjw]

从更好性能、更少重复工作来看，b 的提议更好。
1 是少传数据，2 是只要前端进行判断（可能不需要判断）
如果用 2 的方案，数据多传，后端还可能要进行判断来输出 b:[]（也可能不需要），前端也要进行空判断（也可能不需要）

情况写明白了，那客观上选哪个方案一目了然了。主观的话就不谈了。