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

[darknoll]

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

哪种方案好？

[yaphets666]

其实这是无可争议的.你想就知道了.关系型数据库里头,一个字段没值,是空呢,还是这条数据没这个字段?

[bakujin]

其实我们这么做是为了节约带宽资源

[Twain]

应该先思考应不应该返回，而不是你觉得好不好处理，这个东西本来就没有，为什么还要给你字段呢？先问该不该

[zhuweiyou]

B 没有 不返回, 对我来说 更好判断.
如果返回个 [], null, {} 或者 其它值, 我还有心智负担, 它到底空的时候是啥.

[anson2017]

我觉得都一样，无非是判断 undefined 还是判断空数组的问题

[Zoomz]

后端是用 Java 写的吗，如果是用 DTO 返回的话理论就是第二种（但是 B 返回的为 null ），除非它使用 Map 装的。。

[shew5689]

if("key" in data){} 判断不就 ok 了吗~ 反正合不合理，总有人妥协，不是服务端处理，就是前段处理~

[trlove]

@Zoomz 你忘了可以配置 key 对应的值如果为 null，连 key 都不返回的吗……并不是非得是 map 装

[justsosososo]

没什么合理不合 你不干就后端干 你两都不想干就招个中台来干

[zhangshine]

防御性编程，即使后端返回第二种 ，前端也应该判断会不会出现第一种情况

[bfdh]

@anjianshi 前端代码复杂起来不好保证所有处理这个字段的地方都妥善处理了空值，而后端只要在返回的地方处理一次就好了。

换成下面这种说法是不是也没错？

后端代码复杂起来不好保证所有处理这个字段的地方都妥善处理了空值，而前端只要在接收的地方处理一次就好了。

[pangleon]

这种情况我见过，
公司部分项目约定后端字段为 null 不返回
实际需要看你们的约定，没什么合理不合理，看约定和场景而已
别这么死脑筋，你觉得用不到可能人家一个接口对接好几个前端，别人需要

[yogogo]

前端应该也要所有情况都要考虑到，这样就不用怕后端返回什么类型了

[zishaofei221]

约定好就行了。你不同意，就找他老板商量。
不返回可能是偷懒没 Vo，直接 map 了个数据给你。

[no1xsyzy]

应符合语义。
这样说有点不明不白，还是解释一下：
打个比方，API 请求物品栏内容。那么，一个有物品栏但物品栏为空的角色，和一个没有物品栏的角色，分别是 [] 和 null
但 null 和不存在此 key 应当是同义的（根据 JSON merge patch RFC ）。
说不定还是要推荐一下 GraphQL 之类请求方指定 spec 的方案（中台……

[caijihui11]

这个取决于前端同学的看法，遇到迷惑可以问一下后端同学具体判断逻辑，接口文档只会提供一份最全的接口返回，后端大部分不返回的一些字段是用不到的，能用到的也是有前置条件。
前置条件可能是：
1 某个字段 是否 undefined
2 固定返回某个值的状态

[Yano]

后端序列化 json 的时候，可以指定空或 null 值直接不返回的。
即使后端返回了，你也应该防御编程，判断一下吧。我写接口，前端所有的参数都不信任的，都要校验合法性……

[kangyan]

@bfdh 或许需要一个中台?

[yaphets666]

@justsosososo 当然不是了...合理就是合理 不合理就是不合理 一个字段没有值的时候如何处理,参考关系型数据库...

[cmostuor]

估计没有统一的规范约束着