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

[lsymy]

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

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

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

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

补充一下，本该分页的 table ，硬是不分页。 根据 sort 排序，也不排，就得前端排。
我的意思也不是说这些都是麻烦大事儿，可能很多这种小细节造成我的不满~

[a62527776a]

摸一摸得了 领导都无所谓

[westoy]

搞不好， 你只要碰过， 后端出了点什么问题都是你的锅

搞的好， 后端裁掉， 给你涨薪 15% ，你一个人干一个组的活儿

好吧， 开始选择吧

[miv]

就是提前沟通好约定好格式啊，再干活呀。

[urnoob]

除了 常常修改字段名 其他都好说
如果因为 常常修改字段名 出了什么事故 这个可以怼

[hhjswf]

为什么一定要 restful ？

[en20]

向上反馈,不解决就拒绝联调. 如果这都解决不了说明管理有极大问题,趁早跑路

[Ninja365]

规范问题就不要太较真了，费时费力，这帮懒鬼还不会听你的，尽量向上级寻求帮助，一定要卡住接口文档且不要随意变更，这是前后端对接规范，同时这种事还是要靠自己花费经历去游说和维护，没办法

[wu00]

1 ，不遵循 restful 风格很正常，大部分遵循 restful 的也都是不伦不类的，还不如全 post 用起来省心
2 ，这个该喷
3 ，0 是 0 ，null 是 null ，没毛病，文档上说清楚就行
4 ，这个得看场景吧，有些就是需要前端处理 /计算，以满足不同的展现形式，前端也有部分前端逻辑吧，不可能所有地方都是只管拿到数据绑定就行了。
5 ，“常常”修改是不是填第 2 点的坑呢

[lsymy]

@wu00 中肯
3. 就是没说清楚，就是写了 number 实际拿到 null
4. 需要前端计算的我肯定是完全接受的，有些页面效果编辑后变动这很正常

[lsymy]

@urnoob
实际就是出了问题我才知道他改了字段，然后才告诉我。
也有修改字段删除字段的情况，也不记录，每次费力一个个去对应。

[ivvei]

也就 5 算个问题，其他都是屁大点事

[haoswil]

1. 你有话语权就就摁住给老子改
2. 你没话语权，功能，功能，功能，功能满足就行，管你是什么💩山，你在坐在💩上面，和💩差不多恶心

[8355]

有矛盾上升啊 跟你领导说 让你领导找他领导咯

别急啊 如果领导不在乎就这样好了
有 bug 让测试提给后端

[hhjswf]

@lsymy 干过后端你肯定知道，屎山代码数据库乱七八糟 null ，0 都有，要么前端处理要么后端处理，看谁老实人拗不过了

[bhbhxy]

我公司的后端完全就是在混，返回的字段名称居然是
{
"count(*)": 10
}
纬度给返回 100 ，也不管对不对
接口通不通完全不管，连鼠标点一点都不做，上线了事，bug 全都要前端去反馈，自己从来不测
找领导反馈，领导和稀泥，说不理解我们为什么不能好好沟通
现在明白了，碰上烂人烂事真没办法，只能避开

[lsymy]

@hhjswf
唉，明白这个道理，有些屎就是得吃。

[lsymy]

@bhbhxy 哥们你这个也是夸张的，你们后端是手写 sql 返的吗

[lsymy]

@haoswil 没话语权，所以和你说的一样，和💩一样恶心，那就不操那个心，以后变成💩山也别说我就行

[chaleaochexist]

这样啊.

那我可能会前后端一起做了. 把那个后端架空. 他就慌了.

[sadfQED2]

@ivvei 赞同，也就 5 算个问题，其他的都屁大点事。处理 0 null 都是基本操作，百度地图的 api 有时候都数字文本轮流来，只要后端是 php ，都这德行

[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 "-" ""还有字段命名的问题，剩下的前端计算排序啥的佛系了，能写就写实在麻烦写就反馈上级

[raymanr]

@lsymy 只要别是工资写了 number 拿到 null 就行

[simonCN]

为啥要入前端啊，我发现前端人员普遍不懂计算机知识，如果不是很感兴趣建议早点转回后端。

[maocat]

业务这东西，前端牛逼前端做，后端牛逼后端做

[muzuiget]

自己加一层抽象不就完了，把外部的东西”标准化“后，再传入自己代码处理。

[opentrade]

再过几年，你也不会在乎了

[lingo]

3 和 5 不能接受。但是这都是能通过提前定好接口来解决了。谁不符合接口谁的锅。
其他的都是鸡毛蒜皮的。腾讯的接口都能一个 ID 给你三个名字。re 不 restful 无所谓了，有个标准都好说。前端要计算什么的太正常了。

[dqzcwxb]

遵守 restful 比你剩下的几个要严重得多

[5h4nh]

@westoy 建议选择「搞的好， 后端裁掉， 给你涨薪 15% ，你一个人干一个组的活儿」不用怕，如果你真的忙，老板不是瞎子，会招人帮你打下手的。

[5h4nh]

关于 2,5 楼主可以考虑弄一个 "gate"，例如这个库 https://github.com/typestack/class-transformer

一般的后端框架（ Java Sprint, Python FastAPI ）写 API 接口会定义请求的 Payload 的 Schema(一般就是写个 Class ），反过来想，前端也可以定义 Schema 给调 API 得到的 JSON ，不对就直接崩溃，是字段变了就直接找后端麻烦。

[gbin]

你们后端需要 swagger design first
https://swagger.io/blog/api-design/design-first-or-code-first-api-development/

[darkengine]

create_at, created_at, creat_at, create_time 同一个项目的不同接口 😂

[pubby]

@linl1n “ 上 Typescript 能解决大部分 0 null "-" ""还有字段命名的问题”

怎么解决？

[MEIerer]

是的，后端垃圾前端会不好受，但返过来就没啥事

[weiwoxinyou]

@MEIerer #18 但是前端垃圾用户会不好受

[zqlcrow]

@MEIerer
这还不是因为接口是后端定的吗？
如果接口由前端来定，直接就能恶心死后端。

[oppoic]

这个东西靠自觉，你沟通一次不行，后续再沟通也不可能行
即便这次来回拉扯行了，新接口又不按规矩来，你能怎么办？
技术方面好的方案就是好的，能掰扯的不多，正常你指出一个问题，后端应该抱着感谢的态度才对，大家集思广益把东西做好

[liuky]

需求天天改, 员工天天换, 你指望能有多规范哦, 规则是死的人是活的, 程序能跑就行, 屎山你改了出问题了你的责任, 屎改好了不出问题系统运行稳定你就可以走了, 用不上你了

[abelyao]

@vone 你说的怕不是淘宝的 API (doge)

[op351]

前端直接调数据库坑也很大 没有一个成熟的 orm 系统
graphql 之类的用起来也很操蛋

[maxgorgorCopy]

我自己做客户端 前端 服务端，1 2 3 4 点现在已经习惯了。看什么风格代码都没问题。至于第五点确实该骂后端

[orzorzorzorz]

我刚毕业的时候，得蒙为我引路的老大厚爱，颇被器重。当时也是年轻气盛，碰见这情况不得呼天抢地求爷爷告奶奶地跟老大哭诉，晓之以理动之以情诱之以利：“操你妈的改不改，改不改？不改我就……”那时候老大只是笑笑不说话，也没为难我，只是不了了之了。
当我还在研究轮子，分享会也老是提改改改的方案的时候，老大提桶了，我坐上了老大的位置。
后来有一天，有个新人进来，他看见这一团糟的业务逻辑，对我说：“操你妈的改不改，改不改？不改我就……”
我当时也只能笑笑不说话，也没为难他，只是不了了之了。
只是在心里补了一句：“……就认了。”

[cangcang]

不规范无所谓，只要他永远别改

[Morii]

restFul 又不是银弹，为啥必须要用,,

[duan602728596]

我这以前还见过直接把密码明文传回来的，喷了三个月才改。所以不要神化后端，有些人就是能力不行，只不过他恰好做后端而已。

[lovelylain]

1. 无所谓，全 post 真香
2. 新增的对接时可以纠正，存量的不管
3. 新增的对接时可以纠正，存量的不管，建议用 protobuf 定义接口，字段标准而且不用另外维护文档
4. 看实际情况，如果后端接口并非专门针对你这个场景提供，那么前端计算合理
5. 不应该，类似 2 和 3 ，即使不合理也非必要不修改，前后端沟通好要解决 2 的问题除外
6. 如果分页和排序条件能和 DB 设计对应，就应该后台分页排序，对应不上本身后台也要全捞出来才能排序的话，可考虑前端做。

[xiaojun1994]

后端返回结构都不统一，了解一下

[Yukiteru]

这帖子里这么多嘲讽楼主的回复，怕不都是正好符合楼主描述的后端吧？

[yuningWang8]

习惯就好了。有意见提一下可以，没必要激烈沟通。

另外有一个办法：把经常用的代码封装成组件。后端如果给的接口不一致，直接告诉他们必须保持一致，否则组件不接受就行了。

[spikie]

@lsymy 改字段不通知也太不负责任了

[spikie]

@lsymy 除了 5 ，其他的无非就是工作量的事，他坚持前端那就前端做，工期排出来就好了

[eycode]

有没有可能他们也想改，无力回天怎么改，流水的士兵，铁打的岗位，除了第 5 点外，其他真不算事。如果改了，之前的功能是不是也跟着改，后端规范一改，前端多少功能要改，你摸清楚了没有，不是你一句规范就规范的。项目前期没有规划好，扔锅给老板呗

[hefish]

看起来你得把后端也一并写了。 工资只有一份啊。 去吧。

[huijiewei]

要求不要一次提那么多

先一步一步走

首先变量命名统一了。。。

[ruoxie]

没领导？

[opentrade]

我关了一个这样的 PR https://github.com/rustdesk/rustdesk/pull/3694

[solitude2]

哎，刚入职的我也感觉这里那里不合理，但是大家不愿意或不想听。没有话语权，还是老老实实完成功能吧。改变不了的，选人或制度的问题

[lyonbrown4ddd]

这种让前端手动分页加排序的后端 见一个骂一个

[Outshine]

> 后端的接口不遵循 restful

虽然我写的 API 都是 restful 的，但是我感觉不是 restful 也无伤大雅，只要你们有自己的标准或者不要太凌乱（比如 `/getAllUsersList`）

> 帕斯卡、下划线命名混用，在一个字段可以见到 2 种命名规则，如: `Sum_Money`

这个不太能忍。不过不知道你们同一个数据在不同 API 返回字段是不是一样的命名？比如用户的 `nickname` 在不同的 API 下都是 `nickname` ，而不会出现 `nick_name` 和 `nickName`。


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

这个得分情况，有的数据确实必须得有 0 和 null ，但是有的数据不可能出现 null （比如用户的帖子数）


> 返回的数据需要前端计算处理, 十个字段有五个是要计算的

这个我倾向于后端计算，如果前端计算的话，ios 、安卓、网页端啥的不都得各自写一遍计算代码？如果计算方式需要改的话，前两者还需要重新打包上架，而且每个端都需要改一次。


> 常常修改字段名

这个也不能忍

---

整体来说，你这些点像极了微信的狗屎 API

[fenglc]

@opentrade 您当前访问的页面存在安全风险！
公安机关温馨提醒：
您访问的 http://web.rustdesk.com 该网站被大量用户举报，网站含有未经证实的信息，可能造成您的损失，建议谨慎访问！

[opentrade]

@fenglc https://github.com/rustdesk/rustdesk/issues/856