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

[winiex]

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

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

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

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

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

[jerray]

第二种。如果前端觉得不爽，那就再招个觉得可以的前端。

[zonyitoo]

第一种的后端肯定用的不是强类型的语言来写的，不然怎么可能写得出来第一种。
比如 PHP，Node
用强类型语言写的话，后端自己判断的时候总不可能都是字符串判断和转换，麻烦

[zonyitoo]

实在想不出怎么可能会直接返回第二种，可能正如上面所说，直接 select *出来，不处理直接转成 json 返回去吧。即使是高级一点点的带 DAO 的，也会变成正确的类型。只能说，实在了懒，对质量完全没有追求

[htfy96]

API 的兼容性应该通过明确的 versioning 来解决。旧版本客户端用的应该是 /api/v1，在服务端需要变化 api，且旧版本 API 已经投入使用时，应该完全新开一个 /api/v2 同时保留 v1 接口不变，而不是通过所谓隐式转换这种 trick 瞎猫碰死耗子兼容性刚好碰对

[sunmonster]

@Eoss 牛逼了，编程学到你这种份上也是厉害，不能 if(val === '1') 来判断？

[h1367500190]

@Eoss 看下 #145 楼，这就是为什么说你低估了用第一种方法的人的想象力的原因

[h1367500190]

@Eoss 总之程序能跑就行，类型、语义、可读性...不存在的

[Eoss]

@h1367500190
没收到他的消息提醒，反而收到你的。不知道是我屏蔽了他还是他被降权了。可能人家搬砖还不够多或者不是搬砖的。
随意他吧。反正和我对接我就要求第二种。最近和 java 对接，项目开始前开了个会明确用第二种。

[luoyou1014]

@wizardforcel 不要总是用反问句，这样会显的你攻击性很强。

[luoway]

确实是一场“圣战”了。
问题的核心是兼容别人的问题，还是坚持写好自己的代码？
对于客户端而言，确实不能相信接口严格按约定格式返回。最好使用前校验一遍。
所以虽然第二种很漂亮，但是业务使用中建议第一种，更健壮。

[zhea55]

!( https://imgur.com/a/sTZpGOl)

[jsbin 计算结果]( https://jsbin.com/rosivaqeru/1/edit?html,js,output)



自己写的方法，转化后端 恶心 数据。

[zhea55]



输入对象可以 nest 嵌套其他数据类型。

[HangoX]

@luoyou1014 不会漏。。解析都在统一的地方，你只需要填写 bean 就可以了，蹦是不可能的。

[littlebaozi]

===去判断的时候就得先转类型才行了

[cuzfinal]

有什么好战的，要不然 json 为什么去定义 true、null 这些类型

[zhjits]

非常奇怪为什么有人在生产代码上解析（即使是来自自家后端的）外部数据不做异常处理。

[ConradG]

第一种叫 JSON ……？！（惊
可能经历的少，我还真没见过第一种写法的。

[wizardforcel]

@des 后端的 ORM 会使用反射自动装填对象，它不可能将原本是数值的字段转成字符串，JSON 模板也不会这样做。所以在后端做这件事情实际上是要花费额外人力的。

[rotoava]

数字类型最好全用字符串传递，要不功能都实现不了，谈不上规范。

[collinswang]

这个我觉得是从数据库层传导上来的。
MYSQL 数据库设计的时候，后端表示 true/false 时一般都是用 0,1 来表示，不会用 bool，因为需求一改，要增加一种状态，那非常麻烦，整个底层都得动。
而 null，虽然 MYSQL 数据库有 null，但是也一般设计成默认值为 empty string。
这些就从底层一直传导到前端，变成方法一 的输出效果了