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

[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 了~