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

2020 年 4 月 13 日
 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 是否为空,请问这样是否合理?

是否有相应的设计规范?

8555 次点击
所在节点    程序员
96 条回复
lepig
2020 年 4 月 13 日
干倒后端你就是规范,反之就是“爹”
quan01994
2020 年 4 月 13 日
打一架,谁赢了,谁就是合理。
Vegetable
2020 年 4 月 13 日
不合理, 一级对象零值设计的有问题.
Coulson6
2020 年 4 月 13 日
可以改的,设置字段空的话就不传,都可以定制。不过你判断一下也行,不方便就叫他改改
yukinomiu
2020 年 4 月 13 日
有问题, "数据不存在"和空字符串还是有区别的, 这种表示方法会埋坑(比如如果业务上真的需要空字符的话, 就面临无法表示的尴尬). 设置下数据为空时序列化时忽略就可以避免这个问题, 但是你们的后端没做, 可能因为各种包袱, 也可能因为懒.
orqzsf1
2020 年 4 月 13 日
没什么问题阿
SY413927
2020 年 4 月 13 日
有问题吧
Aliencn
2020 年 4 月 13 日
问题就是浪费带宽,增加了碳排放
hooopo
2020 年 4 月 13 日
不合理 辣鸡后端
nicebird
2020 年 4 月 13 日
无法区分空字符。
dilu
2020 年 4 月 13 日
只要商量好,一切都不是问题

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

规范只要制定好,不存在合不合理的问题。
est
2020 年 4 月 13 日
这就是你们想要的「静态语言一时爽,JSON 输出火葬场」 。因为 A B 都是静态定死的 struct 。23333 。。。。
Bramblex2
2020 年 4 月 13 日
其实重点不是谁改方便,而是逻辑上是否合理。

比如我给你一个空盒子,和什么都不给你,逻辑上是完全不一样的。
tabris17
2020 年 4 月 13 日
@est 可以加一个 isEmpty() 的判断,然后自定义序列化输出就可以了。说到底,还是偷懒呗
shakaraka
2020 年 4 月 13 日
B 应该为 null 或者 B: {a: null, b: null, c: null}

我一直认为把空字符串当做“没有”是坏习惯
Bramblex2
2020 年 4 月 13 日
@wunonglin

B 为 null 和 B: {a: null, b: null, c: null} 逻辑上也是完全不一样的,就像你给我一个空盒子和你什么都没给我逻辑上是不一样的。
Bramblex2
2020 年 4 月 13 日
@est 我以前写 c 艹 后端的时候也没说不能序列化出 null 啊
zhuisui
2020 年 4 月 13 日
要么 B: null 要么 B: {},这才是 B 为空或空的默认值(遵从类型定义)
zencoding
2020 年 4 月 13 日
我一直认为把空字符串当做“没有”是坏习惯 + 1
wyz123723
2020 年 4 月 13 日
后端没给你传 a: 'null'就算不错了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/661896

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX