V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lsymy
V2EX  ›  职场话题

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

  •  
  •   lsymy · 2023-03-23 11:27:42 +08:00 · 6870 次点击
    这是一个创建于 450 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    第 1 条附言  ·  2023-03-23 12:23:45 +08:00
    补充一下,本该分页的 table ,硬是不分页。 根据 sort 排序,也不排,就得前端排。
    我的意思也不是说这些都是麻烦大事儿,可能很多这种小细节造成我的不满~
    80 条回复    2023-03-31 09:53:03 +08:00
    a62527776a
        1
    a62527776a  
       2023-03-23 11:30:34 +08:00
    摸一摸得了 领导都无所谓
    westoy
        2
    westoy  
       2023-03-23 11:37:30 +08:00
    搞不好, 你只要碰过, 后端出了点什么问题都是你的锅

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

    好吧, 开始选择吧
    miv
        3
    miv  
       2023-03-23 11:40:45 +08:00 via Android
    就是提前沟通好约定好格式啊,再干活呀。
    urnoob
        4
    urnoob  
       2023-03-23 11:42:15 +08:00
    除了 常常修改字段名 其他都好说
    如果因为 常常修改字段名 出了什么事故 这个可以怼
    hhjswf
        5
    hhjswf  
       2023-03-23 11:43:41 +08:00 via Android   ❤️ 5
    为什么一定要 restful ?
    en20
        6
    en20  
       2023-03-23 11:45:51 +08:00
    向上反馈,不解决就拒绝联调. 如果这都解决不了说明管理有极大问题,趁早跑路
    Ninja365
        7
    Ninja365  
       2023-03-23 11:46:30 +08:00
    规范问题就不要太较真了,费时费力,这帮懒鬼还不会听你的,尽量向上级寻求帮助,一定要卡住接口文档且不要随意变更,这是前后端对接规范,同时这种事还是要靠自己花费经历去游说和维护,没办法
    wu00
        8
    wu00  
       2023-03-23 11:49:17 +08:00   ❤️ 1
    1 ,不遵循 restful 风格很正常,大部分遵循 restful 的也都是不伦不类的,还不如全 post 用起来省心
    2 ,这个该喷
    3 ,0 是 0 ,null 是 null ,没毛病,文档上说清楚就行
    4 ,这个得看场景吧,有些就是需要前端处理 /计算,以满足不同的展现形式,前端也有部分前端逻辑吧,不可能所有地方都是只管拿到数据绑定就行了。
    5 ,“常常”修改是不是填第 2 点的坑呢
    lsymy
        9
    lsymy  
    OP
       2023-03-23 11:55:09 +08:00
    @wu00 中肯
    3. 就是没说清楚,就是写了 number 实际拿到 null
    4. 需要前端计算的我肯定是完全接受的,有些页面效果编辑后变动这很正常
    lsymy
        10
    lsymy  
    OP
       2023-03-23 11:57:08 +08:00
    @urnoob
    实际就是出了问题我才知道他改了字段,然后才告诉我。
    也有修改字段删除字段的情况,也不记录,每次费力一个个去对应。
    ivvei
        11
    ivvei  
       2023-03-23 11:57:17 +08:00   ❤️ 1
    也就 5 算个问题,其他都是屁大点事
    haoswil
        12
    haoswil  
       2023-03-23 12:02:38 +08:00
    1. 你有话语权就就摁住给老子改
    2. 你没话语权,功能,功能,功能,功能满足就行,管你是什么💩山,你在坐在💩上面,和💩差不多恶心
    8355
        13
    8355  
       2023-03-23 12:03:09 +08:00
    有矛盾上升啊 跟你领导说 让你领导找他领导咯

    别急啊 如果领导不在乎就这样好了
    有 bug 让测试提给后端
    hhjswf
        14
    hhjswf  
       2023-03-23 12:06:41 +08:00 via Android
    @lsymy 干过后端你肯定知道,屎山代码数据库乱七八糟 null ,0 都有,要么前端处理要么后端处理,看谁老实人拗不过了
    bhbhxy
        15
    bhbhxy  
       2023-03-23 12:17:33 +08:00
    我公司的后端完全就是在混,返回的字段名称居然是
    {
    "count(*)": 10
    }
    纬度给返回 100 ,也不管对不对
    接口通不通完全不管,连鼠标点一点都不做,上线了事,bug 全都要前端去反馈,自己从来不测
    找领导反馈,领导和稀泥,说不理解我们为什么不能好好沟通
    现在明白了,碰上烂人烂事真没办法,只能避开
    lsymy
        16
    lsymy  
    OP
       2023-03-23 12:27:43 +08:00
    @hhjswf
    唉,明白这个道理,有些屎就是得吃。
    lsymy
        17
    lsymy  
    OP
       2023-03-23 12:28:44 +08:00
    @bhbhxy 哥们你这个也是夸张的,你们后端是手写 sql 返的吗
    lsymy
        18
    lsymy  
    OP
       2023-03-23 12:31:43 +08:00
    @haoswil 没话语权,所以和你说的一样,和💩一样恶心,那就不操那个心,以后变成💩山也别说我就行
    chaleaochexist
        19
    chaleaochexist  
       2023-03-23 12:32:43 +08:00
    这样啊.

    那我可能会前后端一起做了. 把那个后端架空. 他就慌了.
    sadfQED2
        20
    sadfQED2  
       2023-03-23 12:37:45 +08:00 via Android
    @ivvei 赞同,也就 5 算个问题,其他的都屁大点事。处理 0 null 都是基本操作,百度地图的 api 有时候都数字文本轮流来,只要后端是 php ,都这德行
    bhbhxy
        21
    bhbhxy  
       2023-03-23 13:10:25 +08:00
    @lsymy 工作态度不行,工作能力不行,有一次我用 ES6 的语法提交数据:
    const data = { user, score }
    他接口写得有问题,看了我的前端代码以后,居然说我提交的格式不对,反问我知不知道 JSON 语法,
    非得用传统方法写一遍验证是他的问题才肯去改,水平烂又迷之自信,笑死了
    waytodelay
        22
    waytodelay  
       2023-03-23 14:13:40 +08:00
    对数据完全不做处理,比如一个数字类型,空的时候会有 0 和 null 两种情况

    不知道楼主做的什么业务,金融项目下,0 和 null 不是划等号的
    wcao
        23
    wcao  
       2023-03-23 14:20:31 +08:00
    恩,2-4 工作经验的时候,和楼主一样。
    看见不爽的就想喷,想按照规范来,都想好好写代码。

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

    写自己的项目不香吗,把你所有的规范都可以用到自己项目里。
    timedivision
        24
    timedivision  
       2023-03-23 14:27:51 +08:00
    分页都不分有点过分了
    vone
        25
    vone  
       2023-03-23 14:29:58 +08:00   ❤️ 1
    数字返回 null 就受不了?

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

    这才叫精彩。
    pengtdyd
        26
    pengtdyd  
       2023-03-23 14:35:18 +08:00   ❤️ 1
    《计算机世界里面的任何问题都可以通过加一层来解决》
    imgalaxy
        27
    imgalaxy  
       2023-03-23 14:45:05 +08:00
    {
    ...
    key: [null],
    ...
    }
    来点我司的奇葩
    RealJacob
        28
    RealJacob  
       2023-03-23 15:12:53 +08:00
    你说的很多都不复杂啊,感觉后端稍微一搞就可以
    opengps
        29
    opengps  
       2023-03-23 15:20:42 +08:00
    如果不是从头做起,那么这个规范几乎没有任何意义,因为已经错过了为了规范而规范的时候了。花掉额外的成本去统一老项目,反而会让原本稳定的老项目变得很不稳定,风险代价远大于代码不规范带来的管理问题
    root01
        30
    root01  
       2023-03-23 15:20:51 +08:00
    能不能用? 能用就行了,公司不自己开的
    fiypig
        31
    fiypig  
       2023-03-23 15:31:12 +08:00
    接口文档给你整好,其他负责做就好,做好划水就对了。
    la2la
        32
    la2la  
       2023-03-23 16:14:32 +08:00
    如果没有规范的管理,前端最好关键数据字段都做异常处理,不管后端给的数据标不标准,虽然很麻烦但是可以避免很多坑
    zero47
        33
    zero47  
       2023-03-23 17:03:28 +08:00
    前转后多年。
    看到第一点我觉得 OP 有点矫情,但看到第二点我就支持 OP 去骂后端。关于 0 和 null 这个问题其实要看数据录入方,我做 Android 时都是要判空的,这也是后来为什么有 kotlin 这门语言。排序分页应该是后端的职责,而且能让前端自己实现的,后端做肯定也简单。计算这个确实就是看谁的话语权大,无伤大雅。
    zero47
        34
    zero47  
       2023-03-23 17:08:45 +08:00
    「节省服务器资源等理由搪塞」,这就更应该分页。
    你也可以回怼什么都扔一大堆数据过来,前端占用大,会卡。
    GzhiYi
        35
    GzhiYi  
       2023-03-23 17:10:06 +08:00
    这情况 OP 最好弄一层 BFF 。
    ww940521
        36
    ww940521  
       2023-03-23 17:39:55 +08:00
    这种我以前还会吐槽下,现在都是能用就行,不能用再套层壳处理下,有什么大不了的。
    LeegoYih
        37
    LeegoYih  
       2023-03-23 17:43:52 +08:00
    我怀疑你在内涵企业微信的 OpenAPI
    ljsh093
        38
    ljsh093  
       2023-03-23 17:49:06 +08:00
    @hhjswf #14 正确的,调用方也不一定靠谱,说好了数字类型非得传个"0"
    SenLief
        39
    SenLief  
       2023-03-23 17:54:00 +08:00
    删改字段名都不通知的吗。。。
    linl1n
        40
    linl1n  
       2023-03-23 17:54:05 +08:00
    上 Typescript 能解决大部分 0 null "-" ""还有字段命名的问题,剩下的前端计算排序啥的佛系了,能写就写实在麻烦写就反馈上级
    raymanr
        41
    raymanr  
       2023-03-23 17:55:05 +08:00
    @lsymy 只要别是工资写了 number 拿到 null 就行
    simonCN
        42
    simonCN  
       2023-03-23 18:56:32 +08:00
    为啥要入前端啊,我发现前端人员普遍不懂计算机知识,如果不是很感兴趣建议早点转回后端。
    maocat
        43
    maocat  
       2023-03-23 19:01:10 +08:00
    业务这东西,前端牛逼前端做,后端牛逼后端做
    muzuiget
        44
    muzuiget  
       2023-03-23 19:05:40 +08:00
    自己加一层抽象不就完了,把外部的东西”标准化“后,再传入自己代码处理。
    opentrade
        45
    opentrade  
       2023-03-23 19:21:33 +08:00   ❤️ 1
    再过几年,你也不会在乎了
    lingo
        46
    lingo  
       2023-03-23 21:14:41 +08:00
    3 和 5 不能接受。但是这都是能通过提前定好接口来解决了。谁不符合接口谁的锅。
    其他的都是鸡毛蒜皮的。腾讯的接口都能一个 ID 给你三个名字。re 不 restful 无所谓了,有个标准都好说。前端要计算什么的太正常了。
    dqzcwxb
        47
    dqzcwxb  
       2023-03-23 22:07:55 +08:00   ❤️ 1
    遵守 restful 比你剩下的几个要严重得多
    5h4nh
        48
    5h4nh  
       2023-03-23 22:49:27 +08:00
    @westoy 建议选择「搞的好, 后端裁掉, 给你涨薪 15% ,你一个人干一个组的活儿」不用怕,如果你真的忙,老板不是瞎子,会招人帮你打下手的。
    5h4nh
        49
    5h4nh  
       2023-03-23 22:58:05 +08:00
    关于 2,5 楼主可以考虑弄一个 "gate",例如这个库 https://github.com/typestack/class-transformer

    一般的后端框架( Java Sprint, Python FastAPI )写 API 接口会定义请求的 Payload 的 Schema(一般就是写个 Class ),反过来想,前端也可以定义 Schema 给调 API 得到的 JSON ,不对就直接崩溃,是字段变了就直接找后端麻烦。
    gbin
        50
    gbin  
       2023-03-23 23:40:55 +08:00 via Android
    darkengine
        51
    darkengine  
       2023-03-24 00:29:50 +08:00
    create_at, created_at, creat_at, create_time 同一个项目的不同接口 😂
    pubby
        52
    pubby  
       2023-03-24 08:55:43 +08:00 via iPhone
    @linl1n “ 上 Typescript 能解决大部分 0 null "-" ""还有字段命名的问题”

    怎么解决?
    MEIerer
        53
    MEIerer  
       2023-03-24 09:20:18 +08:00
    是的,后端垃圾前端会不好受,但返过来就没啥事
    weiwoxinyou
        54
    weiwoxinyou  
       2023-03-24 09:42:54 +08:00
    @MEIerer #18 但是前端垃圾用户会不好受
    zqlcrow
        55
    zqlcrow  
       2023-03-24 09:52:11 +08:00
    @MEIerer
    这还不是因为接口是后端定的吗?
    如果接口由前端来定,直接就能恶心死后端。
    oppoic
        56
    oppoic  
       2023-03-24 09:53:31 +08:00
    这个东西靠自觉,你沟通一次不行,后续再沟通也不可能行
    即便这次来回拉扯行了,新接口又不按规矩来,你能怎么办?
    技术方面好的方案就是好的,能掰扯的不多,正常你指出一个问题,后端应该抱着感谢的态度才对,大家集思广益把东西做好
    liuky
        57
    liuky  
       2023-03-24 09:55:17 +08:00   ❤️ 1
    需求天天改, 员工天天换, 你指望能有多规范哦, 规则是死的人是活的, 程序能跑就行, 屎山你改了出问题了你的责任, 屎改好了不出问题系统运行稳定你就可以走了, 用不上你了
    abelyao
        58
    abelyao  
       2023-03-24 10:06:31 +08:00
    @vone 你说的怕不是淘宝的 API (doge)
    op351
        59
    op351  
       2023-03-24 10:12:29 +08:00
    前端直接调数据库坑也很大 没有一个成熟的 orm 系统
    graphql 之类的用起来也很操蛋
    maxgorgorCopy
        60
    maxgorgorCopy  
       2023-03-24 10:23:00 +08:00
    我自己做客户端 前端 服务端,1 2 3 4 点现在已经习惯了。看什么风格代码都没问题。至于第五点确实该骂后端
    orzorzorzorz
        61
    orzorzorzorz  
       2023-03-24 10:48:21 +08:00   ❤️ 1
    我刚毕业的时候,得蒙为我引路的老大厚爱,颇被器重。当时也是年轻气盛,碰见这情况不得呼天抢地求爷爷告奶奶地跟老大哭诉,晓之以理动之以情诱之以利:“操你妈的改不改,改不改?不改我就……”那时候老大只是笑笑不说话,也没为难我,只是不了了之了。
    当我还在研究轮子,分享会也老是提改改改的方案的时候,老大提桶了,我坐上了老大的位置。
    后来有一天,有个新人进来,他看见这一团糟的业务逻辑,对我说:“操你妈的改不改,改不改?不改我就……”
    我当时也只能笑笑不说话,也没为难他,只是不了了之了。
    只是在心里补了一句:“……就认了。”
    cangcang
        62
    cangcang  
       2023-03-24 10:51:00 +08:00
    不规范无所谓,只要他永远别改
    Morii
        63
    Morii  
       2023-03-24 10:55:46 +08:00
    restFul 又不是银弹,为啥必须要用,,
    duan602728596
        64
    duan602728596  
       2023-03-24 12:46:47 +08:00
    我这以前还见过直接把密码明文传回来的,喷了三个月才改。所以不要神化后端,有些人就是能力不行,只不过他恰好做后端而已。
    lovelylain
        65
    lovelylain  
       2023-03-24 13:41:38 +08:00 via Android
    1. 无所谓,全 post 真香
    2. 新增的对接时可以纠正,存量的不管
    3. 新增的对接时可以纠正,存量的不管,建议用 protobuf 定义接口,字段标准而且不用另外维护文档
    4. 看实际情况,如果后端接口并非专门针对你这个场景提供,那么前端计算合理
    5. 不应该,类似 2 和 3 ,即使不合理也非必要不修改,前后端沟通好要解决 2 的问题除外
    6. 如果分页和排序条件能和 DB 设计对应,就应该后台分页排序,对应不上本身后台也要全捞出来才能排序的话,可考虑前端做。
    xiaojun1994
        66
    xiaojun1994  
       2023-03-24 15:13:56 +08:00
    后端返回结构都不统一,了解一下
    Yukiteru
        67
    Yukiteru  
       2023-03-24 16:31:18 +08:00
    这帖子里这么多嘲讽楼主的回复,怕不都是正好符合楼主描述的后端吧?
    yuningWang8
        68
    yuningWang8  
       2023-03-24 17:08:22 +08:00
    习惯就好了。有意见提一下可以,没必要激烈沟通。

    另外有一个办法:把经常用的代码封装成组件。后端如果给的接口不一致,直接告诉他们必须保持一致,否则组件不接受就行了。
    spikie
        69
    spikie  
       2023-03-24 17:29:55 +08:00
    @lsymy 改字段不通知也太不负责任了
    spikie
        70
    spikie  
       2023-03-24 17:31:21 +08:00
    @lsymy 除了 5 ,其他的无非就是工作量的事,他坚持前端那就前端做,工期排出来就好了
    eycode
        71
    eycode  
       2023-03-24 17:37:09 +08:00
    有没有可能他们也想改,无力回天怎么改,流水的士兵,铁打的岗位,除了第 5 点外,其他真不算事。如果改了,之前的功能是不是也跟着改,后端规范一改,前端多少功能要改,你摸清楚了没有,不是你一句规范就规范的。项目前期没有规划好,扔锅给老板呗
    hefish
        72
    hefish  
       2023-03-24 17:47:01 +08:00
    看起来你得把后端也一并写了。 工资只有一份啊。 去吧。
    huijiewei
        73
    huijiewei  
       2023-03-24 23:10:20 +08:00
    要求不要一次提那么多

    先一步一步走

    首先变量命名统一了。。。
    ruoxie
        74
    ruoxie  
       2023-03-25 00:11:27 +08:00
    没领导?
    opentrade
        75
    opentrade  
       2023-03-25 00:21:37 +08:00
    solitude2
        76
    solitude2  
       2023-03-25 05:03:10 +08:00 via Android
    哎,刚入职的我也感觉这里那里不合理,但是大家不愿意或不想听。没有话语权,还是老老实实完成功能吧。改变不了的,选人或制度的问题
    lyonbrown4ddd
        77
    lyonbrown4ddd  
       2023-03-25 08:31:21 +08:00
    这种让前端手动分页加排序的后端 见一个骂一个
    Outshine
        78
    Outshine  
       2023-03-25 17:22:03 +08:00
    > 后端的接口不遵循 restful

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

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

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


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

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


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

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


    > 常常修改字段名

    这个也不能忍

    ---

    整体来说,你这些点像极了微信的狗屎 API
    fenglc
        79
    fenglc  
       2023-03-31 09:37:28 +08:00
    @opentrade 您当前访问的页面存在安全风险!
    公安机关温馨提醒:
    您访问的 http://web.rustdesk.com 该网站被大量用户举报,网站含有未经证实的信息,可能造成您的损失,建议谨慎访问!
    opentrade
        80
    opentrade  
       2023-03-31 09:53:03 +08:00
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2585 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 14:09 · PVG 22:09 · LAX 07:09 · JFK 10:09
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.