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

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

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

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

再补充一下 #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 }

@ruby0906

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

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

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

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

@cassyfar

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

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

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

B 为空你就返回 null 啊

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

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

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

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

@brader

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

不合理。

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

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

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

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

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

不合理。

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

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

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

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

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

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