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

[mouyase]

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



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



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



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



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



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

[oneisall8955]

建议后端重写，什么垃圾后端

[XCFOX]

后端太菜了，跟领导反应给后端上一些强制性的规范，比如让后端接入 OpenAPI 、或者使用 tRPC 、GraphqL 、gRPC 等强类型 API 来实现接口。

好奇什么样的人用什么样的语言能把布尔值写成 0/1, "on"/"off", 1/0, 1/2 ，直接布尔值不就完事儿了，整这么多损人不利己...

[mouyase]

@XCFOX 我们的后端给我感觉就像是把从一些其他地方拿过来的接口和数据没经过封装就直接返回给客户端了，导致客户端经常要判断特别多的业务逻辑才能计算出来正确的数据

[dayeye2006199]

先写 open API spec ，过了 code review 再写接口

[LancerComet]

楼主可以试一下鄙人自用的序列化器，设计参照 JSON.NET ，起码能够解决后端字段不统一问题，前提是项目能够支持 TS 的 DecoratorMetadata

https://www.npmjs.com/package/@lancercomet/suntori

[pengtdyd]

用 nodejs 做一个中间层

[image72]

真实遭遇过，除了像是这种布尔类型的，还有数组，对象这种基础类型，都能返回好多种形式。就这架构还称是 10 年经验，让人奔溃。
待了 2 个星期就赶紧跑路了

[xuanbg]

某些数据可以前端处理，譬如数组转树什么的，但后端一定要规范。

[jasonyang9]

问就是草台班子（滑稽

[murmur]

我们一般认为前台 json 处理简单，所以都迁就后端，尤其是 java 处理 json 太麻烦了

[bianhui]

咋了，改个字段名，分支判断条件会咋样。你是想把公司项目写成国家标准软件程序吗？从来就没有一个规范交什么字段名非得是什么，相反不一样的就情况会很多，例如一个 json 对象中，代表一条数据，关联了一个 id 作为 key ，那么 userid 只能区别开。但是如果一条 json 对象就是一个 user ，那么他的 id 就是你所谓的 userid （状态枚举同理），有什么问题吗？在网络传输中，特别是对于 json ，每个字母都会占用一定的带宽，并发多了都是影响因素，没必要因为你代码想统一而去迎合你，说白了你只是下游，即便有一天你们有个 ui2.0 复用同样的后端接口，也是前端去配合后端。当然我们总喜欢统一的设计风格，这看起来是规范的，也会给开发带来便利。

[lsk569937453]

枚举值一律都是 0,1 往上累加，自己做映射。

[chenluo0429]

1. 在调取后端接口后增加 transform ，保证前端内部业务数据结构定义的稳定性
2. 使用 nodejs 中间层，处理接口差异性，统一返回结构
3. 让后端统一规范与数据结构
4. 提桶跑路

[layxy]

喷死后端

[wu67]

@XCFOX 美名其曰, 以后增加状态可以方便的叠 2 3 4 5...我都懒得吐槽了, 明明一个开关, 除了开和关还能叠出其他状态?

[gzyguy]

加一层 bff

[lans580759]

建议提桶跑路

[paledream]

是否用 0/1 表示这个估计是后端偷懒，直接用数据库的存储了

[Baymaxbowen]

我这里还有 "0"/"1","true"/"off"，现在懒得纠结这种事情了，大家都被公司不断的 push 往前推，垃圾代码就越来越多。所以我现在不埋怨后端了，他们说不定也是不知道从哪来的这种垃圾数据。

[lzgshsj]

再顺着往后，你就知道为什么前端要搞 BFF 了~

[wangtian2020]

后端骂一顿

[aogg]

垃圾前端总有这么多话，就算是一个旧项目也会有垃圾前端问这样的话，还非要赖新来的后端

[kingofzihua]

api 返回结果单独转一下不就行了

[UKnowMe]

@LancerComet #5 感谢你发的 JSON.NET 我之前一直手写的

[Jamy]

客户端在接收到服务器消息的时候,加个中间层,
清洗来自服务器的数据,
这时候你想怎么转就怎么装.当然工作量都是你的.😎

[Quarter]

@aogg @bianhui 两位是受过什么伤么，反应这么大，什么叫“垃圾前端”，什么叫“就应该前端适配后端”，咱就说，如果是自己设计能力不行就好好学习，努力提升一下，同一个项目制定一套标准的编码规范、统一一下接口设计思路都这么难么，同一个对象在不同接口字段都不统一，你们好像表现的很理所当然啊，甚至还骄傲的挺了挺胸，我也没看到测试在对前端进行一比一 UI 还原比对的时候有后端跳出来说“你们这是搞国家项目啊这么严格”“垃圾测试就是话多啥都怪前端”，还什么叫“多做一个判断怎么了”，一个接口让我多做一个判断，十个接口让我多做十个判断，凭啥给前端增加工作量撒，你要是占理还则罢了，居然还能“无理取闹”了起来，真的是“世界之大，无奇不有”

[toesbieya]

楼上吐槽的那两位早被 b 了，经典人菜脾气大

[lyxxxh2]

找个大佬管下 或者自己成为大佬
不然说了没用

[AreYou0k]

后台什么语言, php 吗? 这种一看就是直接拿数据库转给前端都没处理的. 强类型语言一般定义好不会出现这种问题.

[cleanery]

建议提桶跑路

[smirkcat]

是不是用的 php 哈哈，建议换成强类型语言

[potatowish]

老项目是这样的，后端团队没有严格的开发规范和代码 review ，不同的人来接手项目，数据返回形式就很混乱。你不能指望现在接手的人一次性给你全部解决了。你可以类比你对接不同公司的接口，响应成功的状态码可以有 0 、200 、SUCC 、SUCCESS 、OK 等好几种不同的值。

[mouyase]

@AreYou0k
@smirkcat
后台用的 golang （

@Quarter
大概就是这两位这种才会写出来这样的接口罢

[suyuyu]

像极了我司后端，关联查询让前端自己遍历... 邮箱我用 emali 提交死活报错（没有文档），一问才知用的'mailbox'字段

[suyuyu]

@suyuyu email 打错了

[nerkeler]

没办法 Mysql 没有 true/false

[vincent7245]

你们没有接口文档的吗，文档里怎么规定的就怎么写啊

[janus77]

这个时候 强类型工程化语言就起到作用了（没错 点的就是你 java ）
返回不明？直接用 boolean 啊，我不信还有人放着 boolean 不用非要自己定义数字
命名混乱？ java 的 code style 从培训班开始就深入骨髓了，基本上不会出现特殊情况
至于第三点，只要后端的 TO 是同一个，理论上返回类型就是一样的。

[moyt]

@Baymaxbowen 这才是实事求是的玩法，大家都填屎，随便搞搞就完了，别想着代码多漂亮，没毛用

[adoal]

有 7 种办法：长生剑、孔雀翎、碧玉刀、多情环、霸王枪、离别钩、小马的拳头。

[coderzhangsan]

可能后端是多个人迭代开发的，没有统一的规范要求，所以就按个人规范来了，如果涉及多处调用，设计一个字典转换下就行了，不涉及业务直接判断就好了，简单的数据处理而已，没有什么好抱怨的。

[Dongxiaohao]

这种枚举和规范应该是后端的锅吧，我们公司的这种东西只要是一个意思的，命名和枚举值一定是相同的🤔

[MillaMaxwell]

说明你们这项目后端代码就没审，我是后端开发，后端的接口参数命名都需要规范统一，返回给前端的数据需要直接满足业务的需求，不管是 0/1,ture/false 还是 on/off ，整个项目都用一个就行了

[kenvix]

要么打一顿，要么后端堆屎你也跟着堆屎，反正最后都是屎山，规范去他妈

[mouyase]

@coderzhangsan 现在的问题是，每一个接口拿到数据的时候，我们前端都没有办法根据数据的内容判断到底代表了什么状态。不过你说的字典转换确实是现在正在考虑的一个办法。

[mouyase]

@vincent7245 接口文档都是我对接口数据提出疑问之后才去写的。如果没提出疑问，那文档里就是告诉你，这里有这样一个字段，可能会返回 0 和 1 。

[nothingistrue]

前后端分离之后，两端是平等关系，不是上下依赖关系，接口定义要遵循的原则是：谁负责，谁主导；或者谁主导，谁负责。

理想情况下，业务模型（产品负责）、数据模型（后端负责）、UI 模型（前端负责）是打通之后一体设计的，那么前后端的接口开发方式是：前端定义，后端实现。（即时是一后对多前的情况下这种模式也可行，由后端负责将一套核心应用程序适配出来多套接口。）但现实情况往往是，（因为后端人数多、工资高）啥活都会压到后端，前后端接口的开发方式就编程了：后端定义，后端实现，前端被动使用。这时候，既然接口是由后端全权负责的，那么就是屎，你前端也得用。

[mouyase]

@nothingistrue 现实情况确实是这样

[cutecore]

没有管理+人员流动大，一年多就换一批人，是一批人，有人全部接口 post+json ，有人会部分接口 rest ，有人全部接口 rest 即便 path 参数是中文，作为后端都感觉难受但是也没办法

[nothingistrue]

上面说了是本源原因，本来像说些治标的解决方法的，但想想我不是前端，哪能给解决方法。这个方法，还得前端自己搞。

只能作为旁观者，给一些经验。不管是被工期逼的，还是自己水平不行，后端能出这么烂的接口，说明整个项目都是烂的。这种情况下，前端即不要想着自己造轮子去处理，也不要想着逼后端去处理，直接每个接口都手撕代码，才是最能让自己不加班的处理方式。

[tonytonychopper]

这种在对接口的时候就要提出来吧，如果对方不改的话就只能找你的老板反馈，让你老板重视起来之后去推相关的规范。上面有人提到 BFF ，但是我觉得维护这个 BFF 也挺难受……

[coderzhangsan]

@mouyase 后端如果能改就让他改了，没文档至少要让他把字段释义发文本说清楚，这东西具体看人了，有些人团队协作性强，就会去改，反之，说不定会吵一架，所以有时候不是技术规范问题，跟团队和人主观能动性有很大关系，如果你碰到这样的人，也不要生气，犯不着，问清楚各字段释义，出了问题好明确责任。

[dawenxi11]

想起来我们后端 leader 跟我们前端说过的一句话：前端有时候要强势一点，不要惯着后端

[realJamespond]

1,0 true false 对 js 也妹影响啊都是直接 if 判断

[wunonglin]

@realJamespond #54 曾经碰到的 php 后端，所有字段全部是字符串，01 是"0""1"

[wunonglin]

@realJamespond #54 包括 true ，false ，是："true"和"false"，只能说只有你想不到

[AreYou0k]

@mouyase #33 不用猜大概率是 php 转 go 的. 反正我公司就是, php 转 go 也是这种写法.

[ayase252]

先写接口文档，接口文档定了，面向接口文档开发。接口传的不对就是 bug

[AreYou0k]

@realJamespond #54 不是 0 和 1 的问题, 说白了就是没有强类型规范这个概念. 对这种后端来说他们的工作就是从数据库拿数据给前端的. 根本没处理过数据怎么会有强类型的概念.

[luoway]

一般在接口开发时可以商量，对于后端怎么取值都无所谓，也就可能随意取值。
接口一旦上线修改很困难，不仔细评估可能造成线上故障，也就无法随意变更。

[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 接口文档，先找他当面沟通，沟通无果找他领导。

[label]

本质上还是由于项目的不断更新迭代, 新的开发人员不清楚旧业务的命名, 不同的开发人员, 命名的习惯不一样

[bddxg]

直接工作群骂, 让他贷 2 万找个培训班学一学

[doublestart]

@bddxg 这都被你看出来了, 贷款 2 万还没还清呢 ......

[xiangyuecn]

这个看情况吧，只要不是同一个接口里面会变来变去，都不是问题

true | false 这个：如果有文档，遵照文档，其实没啥可喷的🐶

用户 id 这个，问题不大，屎山堆多了就这样了，数据库里面估计也是这样🐶

最大的问题是你在这屎山上用 ts ，自找麻烦，换做 vanilla js 早下班回家抱老婆了😂

[devilweime]

需求今天出，明天就要发版，还管你那么多，照数据库输出弄，出问题查起来还简单，程序运行 bug 还少点

[liubiantao]

先把锅甩出去，在页面上提示接口返回值错误，让测试、领导、老板等看到，让他们遇到 bug 先去找后端，最不济两人一起找，要加班一起加

[woodfizky]

你需要反思下为什么你会跟这样的后端同事共事🐶

正常点的前后端分离架构一般都会提前商定好前后端交互的数据结构和规范的。

如果没有，你们技术 leader 要么不存在要么不干活。

[kongcc]

我司后端就是这种情况，😭

[FakerLeung]

@Baymaxbowen #19
我还见过 "null" 和 "[]"，排查了大半天，就说为啥保存，打印出来也没问题，踏马的居然是字符串！

[MarioLuo]

根据个人遇到的情况来看，大致是项目没有约定规范、不同开发按照自己的命名和风格随意、新人对项目不熟悉、偷懒对第三方返回数据没有转换，说白了还是技术水平问题，但是归根结底还是管理问题。我的建议了就是提出问题和后端人员，讲道理方式沟通。

[xing7673]

没遇到过这样的后端
楼上 2 位显眼包已经 b 了

[RoshanWu]

自己写一个请求库，一个数据转换库作为其依赖，我是这么实现的。这样不仅可以统一 truth 的判断，也能统一 Response 的结构体。

[linl1n]

如果必须上强度就只有试试 json schema ，其他情况只能跟着 api 文档定义好 responseType ，比如公司后端 go ，经常出现 api 文档返回是个数组为空，但 go 没处理返回了 null ，null.map 直接报错， 只好前端规范了在请求到的数组类型.map .filter 等操作之前必须加 ? , 其他对象类型在解属性时加{}

[linl1n]

不同接口拿到不同字段，态度严肃点直接让后端统一字段，否则只有自己加个处理函数转一下，还是得看沟通

[hefish]

前端自己不会判断哒，实在不行用 ts 重写后端。

[ZeroDu]

@bianhui #65 赞成。我觉得有些人太理想化了。

[alleluya]

@coderzhangsan 除了问清楚 还得做好留痕 省的最后领导问责对方甩锅不承认

[kristofer]

哈哈哈，真就是娱乐圈啊。

[leaflxh]

按照文档来

后端写好 openAPI ，前端生成工具生成请求代码，一把梭

[leaflxh]

哎，戾气太重

以后这种问题建议前后端团队打一架，谁赢了谁说的算（