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

[darknoll]

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

哪种方案好？

[midtin]

服务器计算资源和带宽流量永远是最昂贵的资源，在合理的情况下减少后端的判断处理，通过输出更少的数据来节约流量，我认为是没问题的

[lhx6538665]

无所谓，怎样都行，这个问题你也可以问下自己，后端需要你传这种数据，你要怎么传

[killerv]

@andyli9449 如果是我的话，我会用 null 。

[wangkun025]

前端是需求方，前端说啥就是啥。
这事后端没发言权。

[back0893]

protobuff?
导致的没有缺失?

[killerv]

扯到带宽和流量就有点牵强了吧，{"B": []} 和 {} 能差多少流量？网络发展到这个时代，这个成本基本上可以忽略不计。规范是很重要的，语意不明的表达会增加很多沟通和开发成本。

[clf]

像 SpringBoot 的话，很可能是直接配置了 Jackjson 不输出 null 值。先和他确认一下是不是写公司后端基础框架的人规定的。如果需要完整的数据项，可以考虑直接和对方沟通。

我觉得比较大的可能性是为了少写面向前端返回结果的 ViewModel，直接用字段最全的类，从数据库里直接查需要的字段填充，数据库里为 null 的值可能填充了一个 null，所以这个字段被当作是无效字段直接被 json 序列化工具砍掉了。

[cumt21g]

应该保持字段的固定

[jhdxr]

v2ex 的水平下降的有点严重啊。。。无脑站第二种的居然这么多？


@killerv 你都能想到语义了，有没有想到不存在 b，或者 b 为 null，与 b 的值为[]这两者的语义是不同的？

而且无论后端最终写成啥样，前端那边难道不应该始终检查一遍吗？

[gggxxxx]

都什么年代了，还提省流量和服务器开销......
新观念，第二种方法保持字段的固定有很多优势，所付出的成本（开发精力和硬件资源）微不足道。
坚持第一种方法太古典了，其实并没有省事。出了问题后端还不是要一起排查。

[jhdxr]

@wangkun025 你可能对需求方这三个字有啥误解

[jason19659]

第一种,可选字段不判空是逻辑错误

[vincentxue]

我全端通吃, 我的规则就是:
1. 我支持你的想法。我的做法是这样，如果 B 是一个 Object，那么为空的时候返回 null，如果是一个 Array，为空的时候返回 []。
2. 所有的字段都会存在，不允许有时候有 B 有时候没 B 的情况出现。

这种情况下，Web 、iOS 、Android 都不会出问题，特别是 Android，Android 用 Gson 如果不做额外的工作，只要一个字段没有就会抛异常。

我个人认为服务端某种意义上就是为客户端提供服务的，我写接口的时候一直都是本着方便别人麻烦自己的心态。如果双方出冲突，后端应该让步给前端。我最烦那种偷懒的人，明明知道那样做比较好，但是麻烦点，就各种推脱不做。

[killerv]

@jhdxr 同一种类型，不应当存在某个特殊对象不存在 b 的可能性。Json 这种系统间交互的数据格式，不应该存在相同类型但是数据类型不统一的情况。你说的前端始终检查一遍就是额外的成本，如果都按照规范来，就不存在这个问题。

[killerv]

@jhdxr 你这种用冗余代码兼容各种异常情况，看似健壮，实际上是对规范的破坏，带来的是沟通、维护成本的巨大提升。如果前后端都按照规范来，前端根本没必要校验这种情况。

[baixixi]

就这么点事，前后端都是一个 if else 的事，有那么难吗

[codingguy]

不返回 B 也没问题呀。前端直接 const list = response.B ?? [ ] 就好了

[oddisland]

res?.B ?? [ ]

[leeyom]

通常是第二种，第二种数据结构具有完整性，其实这种不管是前后端，如果做的严谨一点的话，前后端都要做判空处理

[wh1012023498]

又到了前后端为了方便不方便争论了，前端方便后端就不方便了，后端方便前端就不方便了。
所以这不是技术问题，这是话语权之争。