公司后端接口格式不规范，前端该怎么办

[lsymy]

背景： 我本来是以后端应聘进入公司的，在独立开发完两个项目后工作内容有变动，转了前端。

然后现在做前端内容一个月时间，发现是个巨坑。 主要包括但不限于：

1. 后端的接口不遵循 restful
2. 帕斯卡、下划线命名混用，在一个字段可以见到 2 种命名规则，如: 'Sum_Money'
3. 对数据完全不做处理，比如一个数字类型，空的时候会有 0 和 null 两种情况
4. 返回的数据需要前端计算处理, 十个字段有五个是要计算的
5. 常常修改字段名

因为这些问题已经和后端激烈沟通过两次，无果。以数据量大，节省服务器资源等理由搪塞，我感觉就是纯偷懒。
所以想集思广益，我明天准备进行第三次沟通。
就查个表干脆数据库放开来让我自己查得了!

[bhbhxy]

@lsymy 工作态度不行，工作能力不行，有一次我用 ES6 的语法提交数据：
const data = { user, score }
他接口写得有问题，看了我的前端代码以后，居然说我提交的格式不对，反问我知不知道 JSON 语法，
非得用传统方法写一遍验证是他的问题才肯去改，水平烂又迷之自信，笑死了

[waytodelay]

对数据完全不做处理，比如一个数字类型，空的时候会有 0 和 null 两种情况

不知道楼主做的什么业务，金融项目下，0 和 null 不是划等号的

[wcao]

恩，2-4 工作经验的时候，和楼主一样。
看见不爽的就想喷，想按照规范来，都想好好写代码。

不过现在嘛，除了第 5 个，会影响我划水，其他的都是小问题。
包括你补充的，table 不分页，前端排序，无所谓，我能排的，都可以放在前端。只要一次返回几 W 条数据接口不卡，用户不说体验问题。我才难得管。

写自己的项目不香吗，把你所有的规范都可以用到自己项目里。

[timedivision]

分页都不分有点过分了

[vone]

数字返回 null 就受不了？

我们公司系统接口的 json 格式，在数值类型有值时返回字符串格式，如“123”，值为 null 时直接给你返回“--”。

这才叫精彩。

[pengtdyd]

《计算机世界里面的任何问题都可以通过加一层来解决》

[imgalaxy]

{
...
key: [null],
...
}
来点我司的奇葩

[RealJacob]

你说的很多都不复杂啊，感觉后端稍微一搞就可以

[opengps]

如果不是从头做起，那么这个规范几乎没有任何意义，因为已经错过了为了规范而规范的时候了。花掉额外的成本去统一老项目，反而会让原本稳定的老项目变得很不稳定，风险代价远大于代码不规范带来的管理问题

[root01]

能不能用？ 能用就行了，公司不自己开的

[fiypig]

接口文档给你整好，其他负责做就好，做好划水就对了。

[la2la]

如果没有规范的管理，前端最好关键数据字段都做异常处理，不管后端给的数据标不标准，虽然很麻烦但是可以避免很多坑

[zero47]

前转后多年。
看到第一点我觉得 OP 有点矫情，但看到第二点我就支持 OP 去骂后端。关于 0 和 null 这个问题其实要看数据录入方，我做 Android 时都是要判空的，这也是后来为什么有 kotlin 这门语言。排序分页应该是后端的职责，而且能让前端自己实现的，后端做肯定也简单。计算这个确实就是看谁的话语权大，无伤大雅。

[zero47]

「节省服务器资源等理由搪塞」，这就更应该分页。
你也可以回怼什么都扔一大堆数据过来，前端占用大，会卡。

[GzhiYi]

这情况 OP 最好弄一层 BFF 。

[ww940521]

这种我以前还会吐槽下，现在都是能用就行，不能用再套层壳处理下，有什么大不了的。

[LeegoYih]

我怀疑你在内涵企业微信的 OpenAPI

[ljsh093]

@hhjswf #14 正确的，调用方也不一定靠谱，说好了数字类型非得传个"0"

[SenLief]

删改字段名都不通知的吗。。。

[linl1n]

上 Typescript 能解决大部分 0 null "-" ""还有字段命名的问题，剩下的前端计算排序啥的佛系了，能写就写实在麻烦写就反馈上级