V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
OldCarMan
V2EX  ›  程序员

是前端改还是后端改?

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

    rt,最近开发中,遇到某些情况,比如:

    • 是返回一个 int 类型/状态等,前端去做逻辑判断(显示控制/渲染),还是直接返回一个字符串之类的结果(或者其他直接结果)给前端...
    • 表单查询是统一用 post+raw,还是说简单的表单不需要 post ,requestBody ,只有复杂的表单查询才这样做?还是说只有新增/修改时,才会采用 post+raw 的形式...
    • 当有一个需求/bug 改动,最好(性能,设计合理性等)是前后端配合着改时,是两边改,还是为了兼容,只改后端...

    • 第一条,个人觉得,直接返回结果会带来几个问题:
    1. 如果改数据必须存储到数据库中,会增加没必要的存储空间;
    2. 增加流量,影响接口网络传输性能
    3. 结果单一,如果需求改动,接口得增加返回更多得新需求数据,不能复用
    4. 接口做过多的逻辑判断,会影响接口性能 当然这种问题无非是前端做还是后端做的问题,前端渲染时,去判断这些时同样需要消耗性能去执行。
    • 第二条,个人觉得统一比较好,即使影响不大,但一会这,一会那的,写代码时的“注意”成本高(写接口时要去判断是用前者好还是后者好,用接口时要去看接口是前者那样用还是后者那样用)。。。

    • 第三条,个人觉得前提是否具有兼容性问题,如果是有,当然兼容性是必须优先考虑的,不过兼容性可能要看改动影响的范围,如果影响较小,后端在原有基础上做兼容改动没啥问题,但如果改动较大,需要从版本上去做兼容,个人觉得此时前后端都得改,而不是某一方硬适配。当然如果没有兼容问题,建议怎么改,对主要的指标(性能,设计合理性,扩展性等)比较好就怎么来,无论谁需要改动。


    PS: 哈哈,这里主要是最近一些经历,比如遇到一个问题需要改动时,同事总会说,这样前端需要改动之类的,让我尽量的去适配前端,让我怀疑是我的工作经历不足导致我认知不足,还是同事太顾着前端了😂,希望大家也留下平时前后端配合遇到的一些问题及解决方案,另外这里不是想挑起前后端对立,只是为了更好的认识问题及解决问题,大家尽管批评指正,谢谢大家回复!

    第 1 条附言  ·  100 天前
    • 非常感谢大家的回复
    • 个人比较赞同大家说的数据字典的形式;
    • 小改动,改原有接口数据和字典;大改动,做版本兼容,路由切换?比如:/api/v1/
    • 开发前定好规范,开发时做好统一。

    另外一个问题: 大家接口响应是怎么样的,我看过这样的:

    1.只用了基本的http code,用来判断网络或资源情况(比如2xx,3xx,4xx ,5xx等),业务的请求结果用响应的code表示(无论是否正常响应),比如:

    {
      "code" : 200,
      "msg" : "success",
      "data" : {}
    }
    
    {
      "code" : 404,
      "msg" : "not found",
      "data" : {}
    }
    

    2.使用http code+data object和 error object的形式:

    • 成功(http code=2xx):
    {
     data: {},
     info: {},
     messages: []
    }
    
    • 失败(http code=4xx):
    {
      "requestId": xxxxx,
      "status": 4xx,
      "message": "invalid xxx"
    }
    

    贴下谷歌云的接口谷歌云接口

    41 条回复    2023-11-13 20:33:48 +08:00
    GooMS
        1
    GooMS  
       106 天前 via Android
    1. Int, 字典
    2. get query
    yigecaiji
        2
    yigecaiji  
       106 天前 via Android   ❤️ 10
    我是前端,所以让后端改
    fox0001
        3
    fox0001  
       106 天前 via Android
    我的意见

    1. 后端返回 int 。至于前端显示什么,怎么显示,后端不应该涉及
    2. 如果接口不是用 json ,只能前后端商量,确定穿什么。如果用 post+raw ,最好是有清晰的文档。不推荐 get+请求参数。
    3. 遇到需求/bug ,当然是根据实际去处理。我们一般是后端处理业务逻辑,前端处理显示和 UI 逻辑。
    qping
        4
    qping  
       106 天前
    1. 一般都是像一楼一样 int + 字典,减少网络传输的时间消耗更重要,int 传输的数据更少,速度更快。现在的浏览器和服务器增加个判断完全不是事情。

    2. 这应该有统一的约定,合理的是 get,post,delete 都用上,但也有公司之前都是统一用 post ,那和约定保持统一是合理的

    3. 前端应该是展示层,负责将数据渲染成界面,后端负责安全/校验/数据加载,运算,保存等等。
    具体问题具体分析

    我还是想说前后端不用卡的这么死,后端也需要学习前端的知识,前端也需要学习后端的知识。
    但 jsp 那个年代,前端只是写写静态 html ,后端什么都做,现在前后分离,职责是单一了,但是更像是流水线工人,对于个人的成长是极为不利的。
    jazzg62
        5
    jazzg62  
       106 天前
    我是前端,我直接改。除非领导要求后端改,或者前端改不了。
    jucelin
        6
    jucelin  
       106 天前
    1. 两个都返回,怎么显示前端自己决定;以后显示内容有小变化,后端一改就行;
    2. 统一用 POST 最佳,前后端不用协商了;
    3. 理论上后端要少改,后端会向多种前端提供数据,影响面比较大。
    darkengine
        7
    darkengine  
       106 天前   ❤️ 1
    3, 结果单一,如果需求改动,接口得增加返回更多得新需求数据,不能复用
    -----------
    如果你们有 app 端,这条刚好相反。如果 app 直接显示接口返回的字符串,如果需求改了(例如需要加个状态改变时间这种), 接口修改 app 不用发版。

    不过这只是个例子,最终前端还是后端改得看具体的需求。
    daydreamcafe
        8
    daydreamcafe  
       106 天前   ❤️ 1
    如果只是一条链路 后端->前端 ,那么哪边修改都能达到业务要求,无所谓。但是我想说后端没必要那样觉得所谓性能之类的不想修改,因为通常有些场景一些接口是要多端共用的,如果 web 、app 都依赖同一个接口,那么是不是要前端的开发修改 2 遍,能在后端确定的事情为什么要在前端修改
    lsk569937453
        9
    lsk569937453  
       106 天前
    1.返回 int
    2.查询直接 get 就行啊
    darkengine
        10
    darkengine  
       106 天前
    @daydreamcafe 是的,我们之前赶鸭子上架的项目也是这样,接口怼原始数据回来,web/Android/iOS 都要对数据处理一遍才能用于展示
    Selenium39
        11
    Selenium39  
       106 天前
    谁拿钱多谁改
    cxshun
        12
    cxshun  
       106 天前
    1. 如果是服务端之间对接,我的建议是直接用枚举,也就是字符串的方式,方式大家理解。如果是前端,那我建议是 Int 值,增加映射关系就好了。
    2. 尽量遵循 RESTFUL ,新增用 POST ,修改用 PUT ,其他用 GET
    3. 如果可能,尽量让后端接口保持原子性,前端来组合。所以,如果一个需求改动,前端可以通过组合来实现的,尽量前端来;如果不行,就服务端配合。
    8355
        13
    8355  
       106 天前
    1.int 控制渲染是前端自己的逻辑,后端不需要为了前端代码修改发版。
    2.统一一个模式即可,协商解决,为了减少扯皮和不必要的沟通成本,全公司统一。
    3.以现有需求和问题出发,最小代价解决问题为前提。
    vyronlee
        14
    vyronlee  
       106 天前
    理论很完美,但实际情况基本都是:话语权小的一方改。
    LLaMA2
        15
    LLaMA2  
       106 天前
    我来讲点道理,

    如果是网页这种的,前端动一下吧.
    如果是 APP 这种还要走正规上架流程的,后端改一下也无妨。

    还有,返回什么格式要始终遵循一样的规则,尽可能,谁都不能说那天没出什么差错。

    友好协商,积极合作,共创共赢!
    skwyl
        16
    skwyl  
       106 天前
    同 1 楼
    int + 字典
    后台定义好字典给前端加载缓存就行
    wu67
        17
    wu67  
       106 天前
    返回原始状态(存数据表里面那个), 映射关系写文档.

    统一 post. 遇到过不负责任的家伙, 写文档完全复制, post get 不改, 导致每个接口是什么方式都要猜, 那不如干脆直接 post 算了, 还分什么 get put delete
    doanything
        18
    doanything  
       106 天前
    基本上都后端搞。别说让前端搞。让前端改他就说只负责渲染。一顿拉扯还不如直接自己改了。
    asmoker
        19
    asmoker  
       106 天前 via Android
    问题②,有时候 b 端系统,查询条件很复杂,使用 get 方法单纯 kv 很难实现查询条件。get 传 body 也有坑,服务端有些框架直接把 get 请求的 body 擦掉了,默认拿不到。看阿里云有一个实现就是 get 方法 params=json 字符串这样,符合 get 语义,但是感觉怪怪的。post 不合语义,但是相对来说实现较简单。
    ben1024
        20
    ben1024  
       106 天前
    后端改,重心放在后端才能踢走前端
    alleluya
        21
    alleluya  
       106 天前
    @vyronlee 确实 谁说话好使 谁就不想改
    mcluyu
        22
    mcluyu  
       106 天前
    不知道你说的前端包不包含客户端,就第一条来说,这个字符串需要前端显示的话最好是直接返回, 除非这个显示不会改动不会增加。

    因为客户端升级成本还是挺高的,APP 要审核通过才能上线,上线还要用户升级才能生效,增加修改了一种状态后旧版本 APP 就不能正确显示了。

    另外可以抓包一些常见 APP 看看, 就拿京东来说, 它的接口返回的东西真是超乎想象的多,甚至一些按钮的 title 都是接口返回的,真就前端只负责渲染那种。
    dw2693734d
        23
    dw2693734d  
       106 天前
    我是后端,前端改!
    RoccoShi
        24
    RoccoShi  
       106 天前
    我是前端, 后端改!
    bojackhorseman
        25
    bojackhorseman  
       106 天前
    状态值的话一般都是枚举 int 型吧
    alittlehj
        26
    alittlehj  
       106 天前
    @doanything 是呀 我们公司前端都是妹子,经常就这样的问题跑你座位上跟你叽里呱啦说一堆 说什么这个我们前端不改 你们接口返回给我,我们不接受什么的,然后你想尝试说服她们的时候 你会发现磨破嘴皮子也没用。。。有这个时间不管是前端后端都早就改完了。。。。造成现在的后果是基本上后端接口能做的都是后端做了,现在等同于把饭嚼好喂她们嘴里
    bthulu
        27
    bthulu  
       106 天前
    前端不改, 后端也不改, 中台改就行了
    aababc
        28
    aababc  
       105 天前
    我们的规则就是,如果是需要发版本的就让后端多干活,尽量让前端保持简单,容易修改。如果是不需要发版的就相对宽松一些,但也遵守前端尽量只负责展示,而不处理过于复杂的逻辑。
    pkoukk
        29
    pkoukk  
       105 天前
    1.int
    2.网关说了算,前后端都没资格说话
    3.看需求,一般情况都是后端尽量兼容前端,因为前端开发周期太长了,发版窗口少
    awalkingman
        30
    awalkingman  
       105 天前
    @dw2693734d
    @RoccoShi 你俩打一架,谁打输了就谁改
    litchinn
        31
    litchinn  
       105 天前
    1. 返回 int ,如果只是为了显示,直接返回状态名也是可以的,大多数情况直接返回 int
    2. 查询请求都是 Get ,不适合放在 url 中的参数就放在 header 里
    3. 哪边改看设计,没有绝对,前端想让后端改或者后端让前端改得拿出理由,如果任一一边改都无所谓那么领导决定,因为要考虑的因素还很多,比如部署时间,部署影响的范围,开发周期等等
    nothingistrue
        32
    nothingistrue  
       105 天前
    作为一个干了超长时间的后端,给点经验之谈。

    一、压根没必要去深究前端做还是后端做,因为绝大多数情况下,两边都可以做。如果不是两边都可以做,那么前后端就还不是两个端。

    二、对于旧项目来说,优先遵循既往习惯。如果以前就是前端做,那就继续前端做,哪怕这次后端改着更省事。反之亦然。如果你不这么做,那么将来改 BUG 的时候铁定要吃苦头。

    三、对于全新项目来说,以工作量平衡为目标,让前端、后端、总架构、项目经理先去协商,协商好了之后,继续优先遵循既往习惯。
    vikaptain
        33
    vikaptain  
       105 天前
    1. 我个人习惯把值返回,再返回一个字符串字段标识该值的含义,前端爱怎么玩怎么玩。
    2. 以前也搞 get/put/post/delete 区分, 现在直接全部 post 。瞎整那么多事干嘛啊。
    3. 这个还是具体情况具体分析。根据实际情况做判断,拒绝教条主义
    以上是项目没有要求的情况,有要求的情况下跟着项目要求走。
    yekern
        34
    yekern  
       105 天前
    统一接收和返回, Web 接口返回和接收数据不管你是 json 还是 form POST 值全统一字符串, 有什么特殊需求自己管自己的 后端自己转类型格式化, 前端也一样
    lolizeppelin
        35
    lolizeppelin  
       105 天前
    1. 用 int 节约带宽就是扯淡,字符串提高开发效率,一眼能看懂的状态用 int 还要想半天
    如果后端状态 int 字段本身很多地方都在用了,才考虑用 int 表状态

    2.说了 100 便了 了,用 http 重定向用 post 传 get 带 body 就完事
    lolizeppelin
        36
    lolizeppelin  
       105 天前
    3. 后端接口都要都要带版本前缀/v1.0 方便更新修 bug,通过多版本接口实现兼容
    andyxic
        37
    andyxic  
       105 天前
    难道不是应该前端要什么,后端给什么。后端要什么,前端给什么吗?这种都不能算上体力活的东西,就是为了不想干找点借口吧
    zypy333
        38
    zypy333  
       105 天前
    考虑未来的变更,影响最小的一方改
    7inFen
        39
    7inFen  
       105 天前
    一些小问题,前端改完,打包+发布得 5 分钟左右,后端可能 5 秒?
    7inFen
        40
    7inFen  
       105 天前   ❤️ 1
    用户量大建议后端改,即时更新。前端改完发布还要刷新缓存,如果用户填了一堆表单提交时发现页面过期会崩溃的。
    dudubaba
        41
    dudubaba  
       105 天前   ❤️ 1
    都可以做,看谁话语权大,如果前端做,那后端在前端眼里就是 “sql boy”,如果后端做,前端在后端眼里就是“切图仔”。所以前后端要”紧密合作”,这样才能达到共同摸鱼的状态。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5715 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 41ms · UTC 03:32 · PVG 11:32 · LAX 19:32 · JFK 22:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.