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

[darknoll]

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

哪种方案好？

[pandanrain123]

合理

[atonku]

前端说了算，毕竟线上问题都是后台加班

[abelmakihara]

后端是 map 一把梭的吗？

[uselessVisitor]

第二种逻辑上比较好，但是后台要多写逻辑处理

[opengps]

总的来说是合理的，不过为了互相方便，能提前协商就更好了。
强制 key 存在可能需要后端额外的开销，将 null 强制初始化一个默认值

[anjianshi]

我是喜欢第二种，我觉得好处如下：
- 逻辑清晰（该有的字段都有，不用另外看文档确认有哪些字段）
- 出 bug 几率小，前端代码复杂起来不好保证所有处理这个字段的地方都妥善处理了空值，而后端只要在返回的地方处理一次就好了。
- 测试抓包排查看数据时也清楚

[raaaaaar]

并不麻烦，主要看前端的想法，之前我和一个前端合作也遇到过这个问题，我们是加上了的。

[lovecy]

你可以要求后端给到 B:[]，但是你最好适配一下没有的情况。。。

[redtea]

属性没有，省流量。

[lepig]

个人觉得就算为空也要返回比较合理，这样对前端开发人员比较友好。
我一般返回之前先判断一下这个 list 是否为空，如果为空就定义一个空数组返回。

[Gehrman]

第二种前端更方便判断

[Takamine]

通常会用第二种，保持结构完整性。

[lemon94]

我是移动端，我们后端是返回{"A"："***", "B":null}
不过对我也没什么影响，用字典转模型的三方工具直接转就可以。
在使用的时候记得判空就好。

[wangxiaoaer]

空也要返回，是搞笑的吗？加入一个用户对象，里面嵌套了地址等信息，难道要返回：

{name:null,age:0,address:{postcode:null,street:null....},.....} ？？

我们一般的逻辑是：首先 null 跟空是不一样的，其次 json 序列化返回的时候自动过滤 null 值

[egoistttt]

第二种，其实如果用个 vo 返回，这种东西都不会很麻烦，可能只是后端偷懒，直接 map 返回给你吧

[caiqichang]

{A:"", B:{ C:"" }} 前端直接 B.C 没问题
{A:"", B:null} 前端直接 B.C 没问题
{A:""} 前端直接 B.C 报错 Cannot read property C

[caiqichang]

Spring Boot 默认的 jackson 没有的属性会返回 null 而不是去掉

[shaoyijiong]

我们的话如果列表为空 就是 {"a":[]} 如果字符为空就是 {"b":null}

[dengjscn]

@caiqichang 大哥你 JS 学的不行啊，B 为 null 咋还能 B.C 呢？

[joyhub2140]

没有数据的字段，并不回返回对应的 key 了，因为大部分及格的 json 解析库都有对应的解析方法，jsonObj.opt(key, fallback)，会判断如果没有对应 key 的数据，会返回 fallback 。