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

你需要 ES 的 Optional Chaining 特性,

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

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

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

这算 B 存在还是不存在？

> 请问这样是否合理？

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

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

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

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

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

严格来说

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

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

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

有风格

没有规范

用 null 好点吧

为啥不用 protobuf 呢。

这个得区分业务场景

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

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

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

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 只需要数据库设计合理通常就没这些问题。

@hxse

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