js
如果再有空，golang

软件设计里面有个思路，就是把变和不变的部分独立为不同的模块，层也一样，分隔变和不变的层，我们把永远可以不变的层提取出来作为底层，把经常变动更改的层作为上层。

v2ex 这个怎么会帮我删除空格？？？我的图没法看了。

如下重画：

后端 1、2、3 .......................客户端 1、2、3
应用层 1、2、3 ....................应用层 1、2、3
接口层.................................. 接口层
+-----------接口定义----------------+

今天又思考了一下，进一步肯定了 1，主要思路在于分层。

后端 1、2、3 客户端 1、2、3
应用层 1、2、3 应用层 1、2、3
接口层 接口层
+ +
+-----------接口定义---------+


我说说 1 的好处：
1、接口层是 json 的一个最简子集，也即只有字符串，那么可以肯定地说，由于这种简化，使得前后端的接口层都会非常简单稳固。
2、接口层可以由单独的底层小组来开发，完成之后把这个接口层提供给前后端多个业务小组使用，业务小组工作在应用层，应用层才知道 json 的全集，包括 null 和对象等。
3、业务小组极其可能经常修改数据类型，注意，此刻要崩也在业务层崩，不在接口层崩，业务小组调试查 bug 的时候不用找接口层小组。
4、无论应用层怎样改动，无需改动接口层。接口层只有 1 个，应用层是多端多应用。

如上，我认为 1 很好。

@james2013
解析库也是依据 json 格式进行封装的,什么?连 json 格式中 null 都不支持的解析库,找一个正规的出来看看 ?. 像你说 nil 这种情况是不会出现的.

---------这里有个误会，我是说后台有可能送的不是 null，而是 nil 或其他。

我的观点是，接口规范和 json 规范是两码事，接口设计不必遵循 json 规范，它们有不同的设计标准。

@james2013

关于{desc:"null"}，如果按我的想法，这里应该是{desc:""}，从未设置过也是“”，也即只有文本字符串的概念。

有很多 json 解析工具的确都可以处理 js 中的 null，然而不一定所有地方都用同一种解析库，也说不定不叫 null 而叫 nil，因而在项目中往往更看重接口的普通性和统一性，容错处理也是这样，这样才能避免坑。印象中---但我可能记错---接口定位为 boolean+int 和 Boolean+Integer 可能在解析包里面的处理就不一样，而这挺容易写混。诸如此类吧，我认为接口应该就平面无对象的，和语言无关，和解析库无关。

@Axurez

是的，后台扔一个 null 之类过来客户端这边很难处理。从编程上说客户端也是能处理的，但麻烦，隐患无穷，绝对不要选择，要考虑：
1、换个后台又会发怎样的数据对象过来？
2、客户端换人之后他还了解这里面的坑不？
3、加班到很晚脑袋发晕时哪个不容易出错？

我在多个项目之后的总结就是，只能是整数或字符串，不要布尔和 null 对象，数组内类型统一，等等。
本主题的 1 是比我更绝对的做法，我暂时不能判断得失。

@Axurez

我的观点是，接口定义上不能有对象这个概念，接口必须是字面的，plain 的。
我前面写了点个人坑，其中不要 null 或空定义就是针对“对象”的。

家庭装的豆浆

说几个接口的坑，不一定对，供参考：
1、数组里面必定同类型，不然强类型语言处理起来麻烦
2、不要用 bool，而用整型 0、1，不然不好扩展
3、不要有 null 或别的空类型定义，整型的话用-1 表示没有，字符串用“”或其他特别串表示没有

差异可能在于两种方式在客户端的出错处理位置不同，难度不同

考虑到语言特性，数值边界，那么 api 接口最好很直白，很傻，并排除任何语言特性的影响

过去的项目是 2，但在数据类型上趟过太多痛苦的坑，考虑以后试试 1

整理得不错。

可以再对比一下 css 里面的 grid 布局。

面试有问题

看完之后想肉翻

career cap，挺好的，提议：远处旅游一下、发展一个业余爱好、好好健身、回家陪陪父母、专业别丢了

这段时间学习 golang，发现下载依赖包的时候也得翻墙，好折腾。

楼上，https://www.v2ex.com 不需要翻墙