后端接口这样设计是否合理

[Bramblex2]

有一个接口会返回如下数据：

{
	A: {a: 'a', b: 'b', c: 'c'},
    B: {a: 'a', b: 'b', c: 'c'}
}

假设当 B 为空时，返回如下数据（因为后端固定了数据结构）：

{
	A: {a: 'a', b: 'b', c: 'c'},
    B: {a: '', b: '', c: ''}
}

然后让前端自己去判断 B 是否为空，请问这样是否合理？

是否有相应的设计规范？

[lepig]

干倒后端你就是规范，反之就是“爹”

[quan01994]

打一架，谁赢了，谁就是合理。

[Vegetable]

不合理, 一级对象零值设计的有问题.

[Coulson6]

可以改的，设置字段空的话就不传，都可以定制。不过你判断一下也行，不方便就叫他改改

[yukinomiu]

有问题, "数据不存在"和空字符串还是有区别的, 这种表示方法会埋坑(比如如果业务上真的需要空字符的话, 就面临无法表示的尴尬). 设置下数据为空时序列化时忽略就可以避免这个问题, 但是你们的后端没做, 可能因为各种包袱, 也可能因为懒.

[orqzsf1]

没什么问题阿

[SY413927]

有问题吧

[Aliencn]

问题就是浪费带宽，增加了碳排放

[hooopo]

不合理 辣鸡后端

[nicebird]

无法区分空字符。

[dilu]

只要商量好，一切都不是问题

你说的这种情况，在我们公司，前端会特意要求这样做而不是给个空对象

规范只要制定好，不存在合不合理的问题。

[est]

这就是你们想要的「静态语言一时爽，JSON 输出火葬场」 。因为 A B 都是静态定死的 struct 。23333 。。。。

[Bramblex2]

其实重点不是谁改方便，而是逻辑上是否合理。

比如我给你一个空盒子，和什么都不给你，逻辑上是完全不一样的。

[tabris17]

@est 可以加一个 isEmpty() 的判断，然后自定义序列化输出就可以了。说到底，还是偷懒呗

[wunonglin]

B 应该为 null 或者 B: {a: null, b: null, c: null}

我一直认为把空字符串当做“没有”是坏习惯

[Bramblex2]

@wunonglin

B 为 null 和 B: {a: null, b: null, c: null} 逻辑上也是完全不一样的，就像你给我一个空盒子和你什么都没给我逻辑上是不一样的。

[Bramblex2]

@est 我以前写 c 艹 后端的时候也没说不能序列化出 null 啊

[zhuisui]

要么 B: null 要么 B: {}，这才是 B 为空或空的默认值（遵从类型定义）

[zencoding]

我一直认为把空字符串当做“没有”是坏习惯 + 1

[wyz123723]

后端没给你传 a: 'null'就算不错了