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

[darknoll]

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

哪种方案好？

[q1angch0u]

月经贴……

[dm4927]

啊，这问题我熟，之前驻场一家公司就是这样的。
后端接口只返回存在值的字段，然后出现了以下问题，之后改成了所有值都传。
第一是，有些接口返回的是 Object 套 Object 的，大概三四层，这就导致了，前端需要一层层的处理。
第二是，因为项目比较大，陆陆续续来了很多人，然后每来一个人，都要和他沟通说明下为什么有的时候有这个字段，有的时候没有，而由于业务原因，好多时候还需要讲一下触发这个字段的方式，沟通成本直线飙升。

[salmon5]

说省流量的，不应该带个狗头吗

[Hoshinokozo]

作为前端，肯定是倾向第二种的，保证数据的一致性能减少大量的的沟通成本和 bug 几率，但是看站内后端老哥的回答第一种在某些特殊情况下也是有一定的道理的，所以说到底这事还是在于沟通，前后端提前商量好，到时候出问题分锅也有依据。

[SyncWorld]

一开始返回的时候用直接扔到 map 里返回，过滤了 null 的 key，直到有一天，连接 ORacle 发现直接扔到 Map 里返回到前端的字段全 TMD 是大写，我的强迫症迫使我又封装成对象返回，这件事充分说明怎么返回都无所谓，关键还是协商问题

[alreadytaken]

最佳解决方案是有的。
背景：最近在捣鼓 vue3+ts 写新项目。
使用 openapi-typescript 连后端给的 swagger，前后端 require，response 定义完全一致，完美解决。

[THESDZ]

我建议返回

{"A":"val","B":null}

因为 null 和[]完全是两码事,根据后端说的话: B 的数据有时候没有 即 B 此时应该为 null

而关于属性不固定等,应该看文档

实际上仍然是协商的问题

[xaplux]

后端返回的 json 格式估计设置了忽略值为 null 的字段，前后端约定好就行了

[qdpoboy]

倾向于第二种。

那假如这是一个开放给外部的 api 接口，那会是那种好呢？如果是字段有值才返回，那文档上每个字段是不是都要写上一句，如果有值则该字段返回，否则不返回

[xumng123]

restful 的接口定义有 option，前端就要按照两种情况处理，大家可以看大厂的接口，他们不会给你 option 返回[]的。

[wangkun025]

@jhdxr 没啥误解。
我是做后端开发的。前端不发 request，我服务器都不开机。

[DogMingDD]

这个就是事情谁来做的问题，没有合不合理的问题。

[exonuclease]

理论上不是应该实例化一个 entity object 怎么能写出来这种代码的

[calmlyman]

各位大佬们写的都是重量级 nb 项目吧？才需要这么省流量吧

[jhdxr]

@wangkun025 厉害厉害，你服务器不开机是谁在那监听前端的请求的？莫非人肉 oncall ？一个请求过来你再开机？

[saberlong]

刚好手头就遇到一个场景。大致是中间层汇聚各种内容一起返回。但是只知道 key,以及值是一个 json 。某项 key 内容不存在时，你让中间层实例化也很为难啊，都不知道内容。

[Rhonin]

@trlove 大厂的屎山都是香的呗？`有时候可能是单条数据 有时候可能是单字符 有时候可能是数组，`合着您觉着这是合理的，不用辩了

[wangkun025]

@jhdxr 阅读能力有待提高。

[trlove]

@Rhonin 不好意思，你可能不知道什么是全局设计。也不懂啥叫泛型，不知道啥叫兼容。你直接说你懒得在前端做判断不就得了，还觉得不合理。不合理您倒是给出您的见解，并解决问题。而不是一句暴躁的不用辩了。您这么高贵，都不辩，那您在在个这个主题下发什么言，原来 v2 的某些前端就这个水平。另外你不认可的设计就说人大厂的就是屎山，我只能说您水平实在是高。拜拜了您嘞

[jimrok]

对于集合，接口永远不要返回 null，用空集合替代 null，对 java 得接口也适用。