可能是另一场圣战：后端返回的 JSON 的值是只要 String 类型呢，还是各种类型都包括呢？

[winiex]

工作中和不同的客户端开发者合作过，有的要求返回的 JSON 统一只包含 String 类型：

{ a: "THYM", b: "107", c: "false" }

而有的则要求数据要表达自己的类型：

{ a: "THYM", b: 107, c: false }

我个人是支持第二种写法的，因为不用再写一堆转 String 和转回类型的代码。大家团队都选择何种方式呢？又是出于何种原因与理由呢？

[iyangyuan]

让我想起了自己刚接触编程的时候，以为编程就是字符串处理

[zwh2698]

没有什么好战的，肯定是第二种，标准就是实践后的总结

[msg7086]

偷懒一时爽，_________。

因为要解决一些开发人员水平不过关而导致的技术问题，特地去引入沉重的技术债？
等过几年的就会被自己挖下的坑给坑死。

当然你也可以跳槽了事，让其他留下来的倒霉员工为你擦腚。

[yhvictor]

选 1 的组织力量开发个 2 转 1 的库吧，这样这个世界就清净了。

[vjnjc]

也倾向于第二种，但感觉第一种更不容易崩溃。

[wizardoz]

既然用 JSON 作为数据交换格式，那么跟两头语言是不是兼容有半毛钱关系？不管对方是啥语言，我都不管，我只要把 JSON 转成自己能够使用的对象。

[chocotan]

第二种

[liuhuansir]

@wizardoz 我也是这么认为的，既然 json 格式标准带了类型，大家都遵守这个标准就行了，把自己的事情做好，屁事都没有

[zhouquanbest]

一切都按标准来 https://www.json.org
毋庸置疑第二种

[Golevka]

要么"严格地发，宽容地收"，要么“严格地发，严格地收“。
想避免应用由于 JSON 的类型问题而崩溃就宽容地收就好了。
所以要求要求返回的 JSON 统一只包含 String 类型是几个意思？能再奇葩点儿不？

[sagaxu]

@hyyou2010 “这里有个误会，我是说后台有可能送的不是 null，而是 nil 或其他。”，这锅后台可不背，你能找个常见的后台 JSON 库用 nil 表示 null 的？

[gnaggnoyil]

@huclengyue 这和静态动态类型有什么关系?你要搞清楚 JSON 规范的类型和语言的类型之间的区别,任何一个图灵完全的语言都可以做到接收一段 JSON 字符串并且判断给定的某个字段的值是不是某个类型的.所以 JSON 规范中的类型更多地是规范本身钦点了特殊值(true,false,null 什么的)的表示方式,从而避免占用 string 所能表示的状态,好让 string 的状态 trival 地一一映射到其所欲代表地语义.典型例子就是"null"用来表示一个由 n,u,l,l 四个字符组成的字符串,而 null 则表示空这个状态.考虑到这个世界上还有不少人的名字(或者昵称)就是"null",把 null 用"null"代替的行为可以说是对目标用户非常不负责.

唯一可能的例外就是 JSON 的 number 本身有精度和表示范围的限制所以在表示超出限制的数的时候不得不 fallback 到 string 上.但这是唯一的例外了.特别地,但凡是有人准备用字符串来代替 null,true 和 false 的语义的,见一个打死一个.

[scriptB0y]

@GreenVine @iwtbauh 原来是这样，那是我孤陋寡闻了，学习了。

[zvving]

肯定第二种。

JSON 标准支持 bool, number, string 就应该合理的使用。使用第一种方案的的确解决了一些问题，但不是合理的解决方案。（设计合理的解决方案要在遵循标准基础上）

简单罗列一些思路：
输出端（服务器）要符合标准，死磕定义
- 合理定义类型：bool, number, string
- 改用 bool 的用 bool，改用 enum 的用 int
- 规范处理 null, "", 0, [], {}
- 常见错误：非数值定义，如手机号、ID，不应该用 int，应该用 string


接收段（客户端）要做的：
- 合理处理类型见自动转换：int <-> float <-> String，包括自定义的：如 iso8601string <-> Date
- 合理处理空、空值：
- 避免 float 精度丢失，数值移除
- 如果服务器输出 json 符合约定，后续业务变化客户端 crash，这锅该客户端背


这些不想清楚，一股脑儿用 string，low ！

[Crabbbbb]

你们这算好了，最近我接的一个 s*接口，返回是类似下面的

"{ a: \"THYM\", b: \"107\", c: \"false\" }"

你没看错，头尾那两个引号真的也给我返回了

[image72]

JSON-schema 包治百病

[wizardforcel]

@luoyou1014 啥叫“类型错误”，类型不应该也是接口的一部分吗？？还变来变去？？

我把 b 写成 "abcd"，parseInt 照样闪退你信不信？？

[wizardforcel]

字符串解决不了任何问题，反而会隐藏问题。

就算你规定了字符串，字符串的格式呢？？客户端期待一个整数，可是接口规定它是个字符串，那我后可不可以传个只包含字母的字符串？

你当然也可以规定“表示数值的字符串”，那干嘛不直接规定成数值？？逗我？？

[des]

说第二种省事的，你怕是没见过 select *之后结果直接吐给客户端的。
话说要是能都是统一的，没有歧义第一种我也能接受。

还有 null 和""是不一样的，以及 enum 我更倾向用直面量，而不是 int

[h1367500190]

@Eoss 你太低估用第一种的人的想象力了

我还见过用 for 循环和字符串拼接 JSON 的。。