前端/客户端有什么办法来处理后端/服务端返回的不规范数据吗

[mouyase]

本人是前端，技术栈 ts/java/oc ，web 和 app 都在做。



现在经常遇到后端返回的值让人难以琢磨。



比如同样都是表示是/否，或者打开/关闭两种状态，有点时候返回值是 0/1 ，有时候是 1/0 ，有的时候是 1/2 ，有的时候是 true/false ，有的时候是"on"/"off"，还有的时候干脆就是为否就没有这个字段了。



或者是同样都是用户 id ，有时候字段叫做 user_id ，有时候叫 UserID ，有时候就只叫 id 。



然后在业务逻辑中经常会出现从不同接口拿到的同一个值，但是是在同一处 UI 显示。就导致 ts 类型定义得定义好几种不同的类型用来兼容。



各位大佬们有什么好的办法来处理这种情况吗？

[AreYou0k]

解决办法就是自己别用强类型呗, 纯属坐牢. 要么就强制他们上 GraphQL.

[bianhui]

@Quarter 谁过激？为什么要道德绑架后端？不说别的，平级关系你还能命令别人咋了？别人设计能力不行，是别人的是，你接不接是你的事。还定制一套规范？你定制？能说出这句话一看就没有遭过社会毒打，就你这样以后还要吃大亏。你有这和我抬杠功夫，多去学习学习或者去外面走走见见世面，你就是太把自己当回事了。做人不用太和自己较真，也不用和别人较真，等你真有资格较真的时候你也明白这个道理了。

[johnnyyeen]

狼牙棒伺候

[zengzizhao]

协议用 protobuf 不就解决了

[bianhui]

补充一点，以前参加过一个项目（上市企业，行业前三）。有个功能数据了大，并发量大，还得防住爬虫，脚本刷。json 字段尽可能减少无用信息，所有对象 key （字段名）设置为一个字母，比如 i 代表 id ，d 代表 date ，s 代表状态。要是突然提供一批这样接口，前端还是不干了，起义还是咋地？不要把所有事情想的美好，就像 on 和 off 的问题，虽然是是否的枚举，但是对后端设计来说定义可能会用面向对象，开关可能就叫 on 和 off 对你来说就是是和非，但是对后端来说是两个显示存在的意义。有时候对你来说一个字段是有是非的含义，但是可能后端来说有“无效”的含义，他可能也会占用一个数值，这样肯定会有差别。至于你说的 user_id 和 UserId 确实有问题，命名规范应该是要统一的。但这不代表他必须要叫 user id ，举个例子，一条交易记录买房和卖方，key 都是 user id ，都叫 user id 怎么弄？这个肯定要看后端设计，可能就叫 id 和 seller id 。说这么多就是想说，世界上没有那么多理所当然的事情，当然你也没有办法要求所有人的想法和你一样，唯一能做的就是求同存异。

[lonjin]

@bianhui 菜就多学

[sayitagain]

这种问题估计就是弱类型语言起步的了。。。我就是 0/1 的代表哈哈哈哈

[dsggnbsp]

@toesbieya 嗯 第一次学会 v2 上怎么 block

[HyperionX]

其实就是后端的一些编程过程导致的：可能存在状态扩展的是 1/2/3 ，数据库存了的是 0/1 ，手搓了业务逻辑的是 true/false 。以前大单体时代一堆接口可能还有一个项目框架限制一下，现在微服务时代基本处于管不了的状态。就算这种通用中间件可能 A 项目用 1.0 ，B 项目用 1.1,C 项目用 3.0 。大部分情况下为了通用性和适配调用其他服务的弹性和自适应，返回的信息基本都是透传，项目内可能压根就没转换过，json 的序列化和反序列化还是比较消耗性能的。
前端的一个项目往往由后端一堆项目的接口组成，经常跨语言跨项目组甚至跨部门跨公司，技术规范都有较大差异。这是分化带来的遗留问题，同时也带来了机遇和挑战。
如果作为前端感觉经常对接一群后端，他们组还不一样，可能收口就在前端，最好自己做 bff ，沟通成本会比自己实现高得多。如果经常只有一个后端对接或者后端就是个单体只给你们提供接口和服务，催他们 leader 写个统一的规范也是应该的。

[darkengine]

我们后端也是这么搞，还自以为很规范，列表没有数据正常会返回 list_name:[] ，丫直接不返回 list_name 这个字段。。。跟他理论还说 go 就是这样的，让前端自己每个字段使用前都要判空。

[ashuai]

1 。 给他套个中间件，把你说的这些输出规范掉。
2 。 劈头盖脸的骂后端，指着他鼻子骂，让他统一规范。

话说你们没有接口文档？接口文档不拉会评审？

[CHTuring]

@bianhui 挺自信的，佩服，人菜脾气大

[344457769]

楼主说这个布尔值让我想起了我接触过的一个项目的接口，里面分别用过 1/0 、on/off 、yes/no 来表示 true/false ，麻了。

[Masoud2023]

有办法，下次上班带刀

[offswitch]

老实接受吧，你一个人改变不了什么，有这种规范的团队少之又少，即使有也不能推行起来，老想着改变环境，然而是你能改变的了的么？

[zerofancy]

相对于类型规范，我认为需求技术评审中明确服务端接口文档才是你们最需要的。只要文档中明确，那么定义成 0/1 还是 true/false 都能处理，遇到"yes"/"no"或"on"/"off"的评审不要通过。

[simo]

已经养成习惯，请求前和响应后，数据都做一次标准化转换。
后端统一与否无所谓，都在格式化转换中做

[Govin]

@bianhui 6 ，你是被社会毒打坏了吧，照你这么说，别人喂你一坨屎，也必须咽下去？

[daya0576]

有啥办法，好好提前沟通呗。每个字段都有它不为人知的故事

[beyondstars]

数据是否规范，以 API 接口文档为准，并且 API 接口文档要经过评审。如果后端传回的数据不符合 API 接口文档，先找他当面沟通，沟通无果找他领导。