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

[darknoll]

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

哪种方案好？

[nicevar]

第一种是合理的，早期在做手机应用的时候还是 wap 时代，那个时候的后端不可能按第二种给你传，本来稍微大点数据都得拆，你一堆空字段还传下来不被喷死。如今虽然网络快了，但是也架不住一大堆网站下发一堆垃圾数据，20 个字段有 5 个是必选的，其他的可选下发一堆空的，真的很蠢。

[asAnotherJack]

楼上好多说用的是 map，不见得，go 里面 list （ slice ）零值就是 nil，不做处理 json 就是 null，加上 tag omitempty 就是直接不带零值的字段了。至于没值还要返回[]，我个人是不乐意做的。

[ichou]

graphql

[laminux29]

@trlove

1.如果接口有 100 字段，那么外加 100 个状态字段是合理的。根据状态字段去进行判断是否要进行渲染，这也是合理的。

2.如果加了状态字段，前端犯了不判断状态的错误，那么很显然这里就只存在这一种错误了，这种错误容易发现，容易排查。但不加状态字段，错误的原因会更多，需要一条条去排查，费时费力。

总之，这种设计是加强鲁棒性的做法，你们这些萌新需要仔细体会，加强学习。

[yazinnnn]

b 没数据就返回空集合啊。。。
你们商量好就行

[agdhole]

前端把 es 开到最新，用 b?. 来取值（逃

[Actrace]

工程化的项目中，基本不存在的协商这种说法。
后端按产品需求考虑所有可能的情况，设计接口，然后文档化。
前端按照文档进行开发，各司其职，没有什么可以扯皮的地方。

[fiypig]

不管有没有，前端就几个判断吧，不然你那边很容易报错

[gimp]

第二种，没数据应该返回空数组，保证字段的类型相同，能减少前端很多不必要的判断，同时也有利于接口自动化测试。

之前调试几个接口，有时候没有字段，有时候回个 null，有时候回空数组，这种不稳定的接口真是一言难尽。

[DreamSpace]

个人理解这要根据业务逻辑来决定。
{"A":null} 代表属性 A 没有对应的数据。
{"A":[]} 代表属性 A 有对应的数据，但数据为空。
具体采用哪种交互得根据业务的真实逻辑来，而不是哪种方便用哪种。

[lizytalk]

也不是不合理。但是得确定好哪些是可能没有的，哪些一定有

[TheWidowMaker]

前后端打架现场…

[lpbname777]

@gimp 最烦这种的

[lpbname777]

用接口就只有一条规则，数据结构要稳定。Array/String 类型的字段不能返回 null，不能不返回

[lpbname777]

@znyq2019 或者就像这老哥说的，都校验 /处理，谁也别跑

[kassadin]

大家能沟通就文档约定，不能沟通就防御型编程，主动降低背锅率。

[OHyn]

都行，要明确好就行。
别 Swagger 上面写了返回 Array,到时候返回 null 或直接没属性。

[linmq]

我倾向第二种

[jdlau]

看到有大量 null 的情况，我有点好奇，这样的设计有没有问题呢？

[lplk]

@trlove 上百字段这个我太有体会了，做转换，有的嵌套列表，没有 key 也加上，就很恶心