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

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

  •  
  •   lsymy · 337 天前 · 6622 次点击
    这是一个创建于 337 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

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

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

    写自己的项目不香吗,把你所有的规范都可以用到自己项目里。
    timedivision
        24
    timedivision  
       336 天前
    分页都不分有点过分了
    vone
        25
    vone  
       336 天前   ❤️ 1
    数字返回 null 就受不了?

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

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

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

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

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

    先一步一步走

    首先变量命名统一了。。。
    ruoxie
        74
    ruoxie  
       335 天前
    没领导?
    opentrade
        75
    opentrade  
       335 天前
    solitude2
        76
    solitude2  
       335 天前 via Android
    哎,刚入职的我也感觉这里那里不合理,但是大家不愿意或不想听。没有话语权,还是老老实实完成功能吧。改变不了的,选人或制度的问题
    lyonbrown4ddd
        77
    lyonbrown4ddd  
       335 天前
    这种让前端手动分页加排序的后端 见一个骂一个
    Outshine
        78
    Outshine  
       334 天前
    > 后端的接口不遵循 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  
       329 天前
    @opentrade 您当前访问的页面存在安全风险!
    公安机关温馨提醒:
    您访问的 http://web.rustdesk.com 该网站被大量用户举报,网站含有未经证实的信息,可能造成您的损失,建议谨慎访问!
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5972 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 06:22 · PVG 14:22 · LAX 22:22 · JFK 01:22
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.