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

[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 是否为空，请问这样是否合理？

是否有相应的设计规范？

咱们就是论事，只讨论技术

不讨论工作，也不讨论后端是不是 xx 。

不要再说什么工作上 xxx，同事 xxx，找认同感 xxx 之类的了。

最后我也没菜到需要在论坛里面找认同感……

[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'就算不错了

[chenqh]

@Bramblex2 c++大佬居然写前端去了，这!!!!

[superrichman]

送礼送个包装袋给我，还要我猜里面送的是什么礼物？？？

[wysnylc]

合理

[mlxy123123]

@est 我看你是看不起我们全 Map 教

[buffzty]

方案 1: interface Resp{
A:{a: string, b:string, c: string},
B?:{a: string, b: string, c: string}
}
方案 2: interface Resp{
A:{a: string, b:string, c: string},
B:{a: string, b: string, c: string}|null
}

[fancy111]

哪有什么设计规范，不过是前后端互相协调而已

[chendy]

建议打死，用个 null 会死么

[Chenamy2017]

后端不要把这些垃圾数据抛到前端去。

[ZSeptember]

看 API 定义，都可以讨论
一般是返回 null 或者不返回 key

[ChineseCabbage]

不合理，把数据丢给前端处理的都是垃圾后端

[Lonely]

@est 这跟静态语言有啥关系？这种回答还有人感谢……

[wunonglin]

@Bramblex2 #16

所以才建议你用 B: {a: null, b: null, c: null}

[Bramblex2]

@chenqh 阴差阳错，当了一年前端 leader，然后再找工作的时候发现如果再去找其他方向的话，可能比较难拿到我理想的薪资，总之还挺蛋疼的

[Yuicon]

同样的工作 前后端谁做都可以 看来你们前后端关系紧张

[cassyfar]

后端来搞笑的吧 B 空的话是{}
建议 B 用 null 的，这是 B undefined，不是 B empty，还是有区别的。

[Cowhitewhite]

我们这都是听前端的，他们是大哥。

[Bramblex2]

@cassyfar 确切的说 undefined / null / empty 在逻辑上是不一样的，undefined 是不该有这个字段，null 是指有这个字段但是这个字段里面可能没东西，{} 是指这个字段里面有东西，但是没内容。

比如举个简单例子:
profile: null 是指我们没有 profile
profile: {} 是指我们有 profile 但是里面没内容

这是很大区别的。

[Bramblex2]

@Yuicon

其实我追求的是「正确的是什么」。在工作上的话必然有很多 dirty 的东西不可避免，但我觉得不能因为 dirty 而放弃对正确的追求，否则自己的下限会越来越低，当有机会能去做正确的事的时候，可能就会因为惯性无意识的选择 dirty 的方法而不是正确的方法，也就是所谓的初心变了

[sagaxu]

@est json 可以忽略 null 字段

[est]

@Bramblex2 当然 Nullable Type 也能实现，写起来不觉得绕么。。
@tabris17 实现当然都可以实现。就是在静态语言里，膏药要随时到处贴上。。。
@mlxy123123 全 interface 教。。。
@Lonely 跟语言的确没啥关系。但是极有可能是全面依赖的东西传了一个固定形态的 struct 然后手上要输出 JSON 就直接序列化出去了。

[vevillive]

若是返数是这样的结构，那么，前端展示应该是取 a 、b 、c 的值，这时候，前端顺便判空就好了，因为还有可能 a 、b 、c 只有某个为空的情况。当然，要后端判断全为空的时候给你个空或者不给也行，但是前端的逻辑又要加多一层判断

[Yuicon]

@Bramblex2 追求正确没问题，不过最好是限制自身，你觉得返回格式不正确可以写工具转成自己想要的。之所以这样妥协只是觉得这种事很多时候争不出什么结论。

[ayase252]

问题在于主楼的接口定义暴露了后端的实现细节。哪一天空的定义变的话，前端还要跟着改

[windychen0]

我觉得吧，大概 B 为空的时候传成{A: {a: 'a', b: 'b', c: 'c'}}就好了吧。。。我们前端判断都是 if(data.B){//to do something}的

[purensong]

作为一名后端，规范是我来定，前端可以提意见，我尽可能满足，不满足就让她保留意见。。

[tds]

我觉得这是一个沟通问题，以前前端还专门让我装过这种数据，他图用起来省事。一两句代码花不了两分钟，何必搞得这么僵呢。。以后总会碰到一些可能前端不好做，后端好做，或者后端不好做前端好做的东西。真就一步不让，各做各的，最后对大家都不好。

[oneisall8955]

有问题，我觉得{A: {a: 'a', b: 'b', c: 'c'},B:null} 比较直观

[Bramblex2]

@tds

你说的对也不对。

对是因为工作上塞垃圾代码的确没有问题，反正能跑就行，没必要跟同事闹僵。

不对是是因为基于对技术的追求，不能降低自己对技术的审美标准。我自己写的接口和带的后端绝对不能给我写这种垃圾代码。

[Bramblex2]

@Yuicon

所以一般作为前端我自己都会专门写一层兼容层，专门处理类似这种数据。
因为我自己也写过 3 年后端，我自己肯定是不能容忍自己给到别人这样的数据的……

[ISSSSSSS]

一般前端会要求传 B: {a: '', b: '', c: ''} ，而不是直接把 B 中的 abc 干掉。

[wanacry]

@Bramblex2 #48 你已经有了自己的判断,而不是不懂来发问,那么你发帖的目的是来找认同的吗

[chendy]

@est #40 nullable 就 nullable 呗，有啥绕的

[raynor2011]

很多时候前端要求这么传，因为前端懒得自己构造

[feelinglucky]

一句话：null 和 empty 的区别，显然不合理

[wusheng0]

个人认为让后端先做个判断比较好

[Bramblex2]

@wanacry

我的认同感还没廉价到需要在这里找，我随便发篇文章都比这强。


我自己当然是有判断的，但我的判断当然也是不一定对的，所以才发帖让大家讨论。我又不是爬虫机器人，也没办法不代观点发帖啊……

[alienx717]

我做后端，我都觉得这个设计的有点烂，不友好

[ruby0906]

我曾经就是这样一个后端，和公司的前端产生了类似的纠纷，我觉得你可以借鉴一下。

当时我先写好了接口文档，前端看了也没提出什么意见，后来他实现的时候，提出各种要求，我没有同意。最后前端按我定的标准实现了。

当我以为一切都 OK 的时候，这个前端写了一封万字信，发给部门领导以及所有技术同事，描述他的心理感受，前后端标准，委婉吐槽等等。。

当时就觉得很难受，我要不要和他公司范围邮件辩论。不辩论吧，被人含蓄的吐槽。辩论吧，又是一件小事，懒得写俺么多字，又不想升级这件事。最后以我的忍耐告终。那感觉就像吃了一记闷亏。

所以，楼主你看看，要不要学习我那同事。。给公司领导和全部技术同事发一封吐槽信。。绝对比来这里找认同感心理会舒服多了。

[MonoLogueChi]

感觉不合理，不是固定结构不合理，是输出 '' 代表 null 不合理。

具体固定结构是否合理，还要看具体使用情况，我是搞后端的，一般我会输出

{
“A": { "a": "a", "b": "b", "c": "c" },
"B": { "a":null, "b": null, "c": null },
}

[Hstar]

这破结构我知道，前端需要，因为他们懒得判断 B 这一层到底是不是一个空对象，直接进入最后一层去判断
后来吃饱了趁着还构造一个这样的结构啊

[noobsheldon]

让我们先来定义一下“合理”中的“理”，不然公有公的理，婆有婆的理。/doge

[LokiSharp]

前端用 TS 就没这么多扯皮的了

[cassyfar]

@Bramblex2 那应该不是 profile: null, 而是压根没有 profile 这一项。

[MonoLogueChi]

再补充一下 #59，我是写 C#的，"B": null 和 "B": { "a":null, "b": null, "c": null } 是完全不一样的，在 C#里，"B": null 表示 B 对象是 null , "B": { "a":null, "b": null, "c": null } 表示对 B 对象初始化过后，B 内的元素都为 null，用代码说就是

var B; 或者是 var B = null;
var B = new B(); 或者是 var B = new { a = null, b = null, c = null }

[Bramblex2]

@ruby0906

我们只讨论技术，不讨论工作。工作上的话沟通解决就行了……

[Exin]

设计接口的时候都面向前后端沟通语言进行设计，楼主的情况就应该是按 JSON 设计，或讲究点来说是 JSON schema，设计完了前后端再各自向自己的语言转换，私以为这是最稳妥最不容易撕的。

就像人与人讲话，一个讲中文（ JavaScript ）的好，一个讲英文（ Python ）的棒，根本讲不出结果。站到中间地带才行。

当然实际执行的时候通常后端比较强势，照着自己语言方便就给了一些 JSON 的 hack 用法，这属于沟通问题了，是另一回事。

[Bramblex2]

@cassyfar

你的办公室里面有三个工位分别是 A, B, C 。

那 A 工位没有人和没有 A 工位逻辑上是一样的吗？

没有 profile 字段对应根本没有 A 这个工位。
profile: null 对应 A 工位上没有人。
profile: {...} 对应 A 工位上有个 {...}

[tomwan]

B 为空你就返回 null 啊

[Bramblex2]

@ruby0906 说句不好听的哈，我找认同感发篇文章绝对比在这讨论强，起码我发文章还有粉丝看，一般都会认同我，何必来这里找不自在呢？我只想从技术上面逻辑上面来讨论这个问题，仅此而已。真的别以己度人。

[ai277014717]

根据业务需要，B 中的 a，b，c 是否需要单独判空。不需要直接不要返回 B 就好了。只需要判空 B 就好了。

[brader]

个人看法，其实我觉得大家说的两种都没有问题，关键有两点：1 、该项目主要由谁来制定标准，该标准是否在各个客户端兼容性良好。2 、风格要统一。
什么是风格要统一呢？就是比如：你这个项目，数据结构用的是第一种，那就从头到尾都用第一种风格；用第二种亦是如此。
满足了这两点，我觉得前后端沟通成本就能有效降低，达成共识后，双方也就不再会纠结，这个接口怎么返回这种，那个接口怎么返回那种。

那么说下，既然风格统一有这么多好处，还会出现多风格的接口呢？出现这个往往都是有历史原因，经手人比较多，后来的人，不够了解前人的风格和做法，最后就造成了这种局面。
如果你看不惯目前的局面，要坚持自己的标准，那么请统一它、重构它。请问你做好这样的决心了吗？没有的话，请不要吐槽它，因为你自己也并不想花时间去改造它

[Bramblex2]

@brader

我已经重构了我们项目的大概 1/5 了……张口就来，以己度人

[dorentus]

不合理。

前端遇到 B: {a: '', b: 'a', c: ''}算什么？

[brader]

@Bramblex2 既然自己有主导权，也在重构，那么你可以做到统一风格了，我认为，你无论采用哪一种风格的接口，和前端解释一次，说之后都是采用此种风格，我相信一个能正常沟通的前端，都不会去纠结这个东西。

如果你仅仅是想知道，那种风格看起来比较标准，我平时是比较喜欢：B:null，前端有提出要求的话，我也是很乐意改的

[star7th]

如果我是那个前端，后端这样写接口给我的我我绝对吐槽回去。

[thet]

无法区分对象空和字符串空值，正常的应该返回 Null 或不传吧，不过这也要看你们团队了

[CasualYours]

不合理。

当后端接口返回：
{
A: {a: 'a', b: 'b', c: 'c'},
B: {a: '', b: '', c: ''}
}
你完全不能区分 B 是 null 还是 {a: '', b: '', c: ''}，当然也不能排除说你们的业务定义中 B 和 {a: '', b: '', c: ''} 是一致的。

我认为的接口设计规范就是在满足需求定义的前提下，前后端协商到达双方的最大便利，从而简化开发流程。

[CasualYours]

@CasualYours
当然也不能排除说你们的业务定义中 B 和 {a: '', b: '', c: ''} 是一致的。
修改为:
当然也不能排除说你们的业务定义中 null 和 {a: '', b: '', c: ''} 是一致的。

[cassyfar]

@Bramblex2 A : {} 对应工位 A 没人，A : {1: {...}} 对应 工位 A 有员工，ID 为 1

没有工位 A 的情况是以下，A 不会出现在返回中。
Data: {
B: {1: {...}}
}

[zhang77555]

具体场景具体分析,没有场景只谈设计没啥意义, 一般来说是会区分 null 和空串.

[dioxide]

你需要 ES 的 Optional Chaining 特性,

[imbacc]

前端拦截处理下就可以了。又不是不能用[dog]

[ironMan1995]

最近两个项目我和后端们配合是我根据功能定义接口格式给他们，然后大家觉得还行就用我定义的。如果后端不好实现就妥协，反正没闹过矛盾。

[wangyzj]

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

这算 B 存在还是不存在？

[adoyle]

> 请问这样是否合理？

对前端合理，还是对后端合理，这要看每个研发角色各自的上下文。通常来说，说不合理只是现有的技术栈不容易实现或者不兼容。我认为这没有通用的答案，因为这是跟具体项目和人相关的。

> 是否有相应的设计规范？

我觉得可以针对返回的数据结构设计一套类型系统。比如 A 类型、B 类型，它们有哪些可选字段、必选字段，字段类型是什么，可以用 JSON Schema 来表达。
然后定义空类型的固定表达，比如类型是字符串的 a 是空的情况，用 `{a: null}` 还是 `{a: ''}` 还是 `{}` 来表达；类型是数组的字段 b 用 `{b: []}` 还是 `{}` 来表达？统一风格就好。
或者直接用 GraphQL，你可以参考它的类型系统 https://graphql.org/learn/schema/#type-system 。
至于具体构造哪些类型，这是从业务角度来思考的。

最终你们会约定出一套 Schema 文档，以此为约束，互不侵犯。

[hxse]

这么较真, 老板给了你多少钱

[dddd1919]

严格来说

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

这几种看起来都是在表达 [空] 这个概念，但每个结构表达的场景都是有区别的，你所说的空到底指的是哪一种，那就用哪一种，表达简单直接最好

[lewinlan]

要看具体的业务含义。
B:{a:'',b:''}是零值，B:null 是空值。
不过看你的描述应该用后者~

[Jooooooooo]

有风格

没有规范

[CantSee]

用 null 好点吧

[p1gd0g]

为啥不用 protobuf 呢。

[jrient]

这个得区分业务场景

[jrient]

比如 你需要根据 b[a]b[b]b[c]渲染，那这样就没什么问题
如果 b 是一个整体，需要整体非空判断，那这样设计就有问题
具体情况具体处理

[cszchen]

把前端后端一起干了，干我一样就没有这种烦恼了

[encro]

结构应该表意，这是写代码基本规范，应该尽量遵守。

users:null vs users:[] 通常后者能明确告诉我们这是一个空的 User 列表
user:{} vs user:null 通常后者表示这个用户不存在而不是这用户存在但是属性为空
user: {id:''} vs user:{id:null} 区别是一个表示 id 为空字符串，一个表示 id 没有设置
user:{orders:[]} vs user:{orders:null} 当然选前者
book:{author:null} vs book:{author:''} 当然选前者
book:{author_name:null} vs book:{author_name:''} 应该还是选前者表示作者名未设置而不是被设置未空字符串，但是这条动态类型语言比较难办，那么可以商量来。

以上可以衍生到数据库设计上。

如果以上很难办，
通常是因为缺少一个合适的框架，
比如 django rest 和 yii rest 只需要数据库设计合理通常就没这些问题。

[Bramblex2]

@hxse

我较真不是因为老板给我多少钱，而是几年后新的老板能不能把给的我的钱再翻个倍。