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

[lsymy]

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

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

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

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

[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 点现在已经习惯了。看什么风格代码都没问题。至于第五点确实该骂后端