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

如何看待后端接口带出数据库全部字段

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

    直接从数据库中取得模型,不需要的值就是一堆 null

    如果是需要额外处理的字段,就在原本对象内放一个 params 的对象,再嵌套一层放处理的数据

    能因为一个值需要转换一下数据而扯皮,哪怕是取模于 10 这种简易操作也要前端来做

    图 图

    128 条回复    2022-04-16 11:03:48 +08:00
    1  2  
    zilongzixue
        1
    zilongzixue  
       81 天前   ❤️ 1
    null 值有什么问题,现在前端框架的表单不是自动处理 null 值的吗
    mokevip
        3
    mokevip  
    OP
       81 天前
    @zilongzixue 为什么要多出来这些数据呢?
    yedanten
        4
    yedanten  
       81 天前 via Android   ❤️ 3
    单纯的偷懒行为,还有模型字段名和数据库字段名如果是完全一致,算是低危的信息泄露
    dicc
        5
    dicc  
       81 天前
    你知道我爬 Twitter 什么感受不,那字段。。。
    putaozhenhaochi
        6
    putaozhenhaochi  
       81 天前 via Android
    让后端加个 entity 转成 VO
    xgfan
        7
    xgfan  
       81 天前   ❤️ 3
    后端又懒又菜。
    懒是因为用了一个巨大的万能对象应对所有接口。
    菜是让人发现这么做了。
    arthas2234
        8
    arthas2234  
       81 天前
    null 值是可以加个配置过滤掉的,直接返回数据库字段肯定不可行
    很好奇,用户表也是这么做的吗,我看第二张图里面还有 oldPassword 这个字段,也是厉害
    cweijan
        9
    cweijan  
       81 天前   ❤️ 1
    其实就是偷懒, 后端懒得建个 DTO, 直接返回数据库实体.
    learningman
        10
    learningman  
       81 天前   ❤️ 2
    入侵最喜欢这种了,sql 注入的时候猜表累死人
    mokevip
        11
    mokevip  
    OP
       81 天前
    emmm ,我因为这个问题和他们怼过无数次,我是给不了啥建议了,暂时救不了他们
    mokevip
        12
    mokevip  
    OP
       81 天前
    @dicc 啥感受
    mokevip
        13
    mokevip  
    OP
       81 天前
    @putaozhenhaochi 有没有文章这种,因为我是前端,对这个不太了解,后端是 JAVA 的
    mokevip
        14
    mokevip  
    OP
       81 天前
    @arthas2234 所有的都是 = =
    lmmlwen
        15
    lmmlwen  
       81 天前   ❤️ 1
    没时间啊,这就是最重要的,而且返回的数据结构这种东西对个人来说并无任何实际价值。我看有人说菜,这和菜没什么关系,谁不知道处理返回的资源,核心原因就是不是自己的东西不心疼
    clf
        16
    clf  
       81 天前
    就是没写 VO 的问题。

    实在偷懒其实可以在类上加上 @JsonIgnore 这种注解就可以了。
    xujinhui1
        17
    xujinhui1  
       81 天前
    既然你都说了,以后出问题都是他们的锅。他们还是不做你就直接不用管即可,你把你分内的事情做好,早点把活做完摸鱼学习不香吗。
    cheng6563
        18
    cheng6563  
       81 天前
    又不是不能用。
    后台的框架模板或者代码生成器就是这么返回的呗,所以说你不喜欢就单独开个接口。
    既然都用快速开发框架了,肯定以开发速度为重,这种低危漏洞也无所谓了。
    spicecch
        19
    spicecch  
       81 天前
    你可以先开发,然后自己写好接口文档并定义字段,让后端来接
    iamqiwei
        20
    iamqiwei  
       81 天前
    是不是用了若依的框架,这个框架本身就这样,我公司也是这样
    golangLover
        21
    golangLover  
       81 天前 via Android   ❤️ 1
    垃圾后端呗,还有什么原因
    DinnyXu
        22
    DinnyXu  
       81 天前   ❤️ 1
    后端返回这种有很多 null 值的字段是因为后端在查询的时候调用的是一个通用方法,这个通用方法对应的就是表结构的字段,也就是 domain 。如果你需要只返回一些有数据的字段,后端需要将 domain 转换为 VO ,或者是直接写 SQL 查询映射 VO 。这种返回很多 null 纯粹是涂方便,也不算是懒,只能算不规范.....
    mokevip
        23
    mokevip  
    OP
       81 天前
    @xujinhui1 小公司,我算是前端的管理,还是不能完全摸鱼不管的。。
    mokevip
        24
    mokevip  
    OP
       81 天前
    @iamqiwei 卧槽,一样!
    pelloz
        25
    pelloz  
       81 天前
    这种情况一般出现在后端不知道前端需要什么字段,只知道前端需要这个业务内的字段。总的来说就是没人设计 api ,靠猜进行开发。
    mokevip
        26
    mokevip  
    OP
       81 天前
    @spicecch 那后端炸了哈哈
    westoy
        27
    westoy  
       81 天前
    不涉及安全(比如泄漏密码啊, 或者返回跨权限的字段)问题其实没什么毛病, 对 CDN 和后端缓存都挺友好的
    rabbbit
        28
    rabbbit  
       81 天前
    别纠结这个,如果领导没说就别管,出事了也跟你没关系。
    对前端没影响,而且以后缺了啥字段也好取。
    到时候得罪了后端,布尔值全给你返回来 1 0 。
    R18
        29
    R18  
       81 天前
    @yedanten
    想请教一下,数据库列名不也是语义化的吗。难不成返回前端的时候要另改一个名字。
    zzc032003
        30
    zzc032003  
       81 天前
    @putaozhenhaochi
    为什么必须要转化啊? 如果仅仅是把字段名改名,意义何在哪?
    Bingchunmoli
        31
    Bingchunmoli  
       81 天前 via Android
    第一如果接口不是面向业务开发而是面向数据开发,针对数据做返回是没问题的,如果针对业务就考虑前端处理和后端处理的优缺点,前端处理是大部分情况吧因为无所谓安全,只是展示,但是后端性能有点影响,前段在用户侧用前端可以节省一些后段性能
    Bingchunmoli
        32
    Bingchunmoli  
       81 天前 via Android   ❤️ 1
    @iamqiwei ruoyi 是生成,如果你需要业务处理也可以写啊,面向数据的借口又不知道你业务需要忽略
    Bingchunmoli
        33
    Bingchunmoli  
       81 天前 via Android
    @clf 但是有的接口需要呢
    Bingchunmoli
        34
    Bingchunmoli  
       81 天前 via Android
    @xgfan 小公司这样很普遍,因为你做 vo 又不增加工资,卖出去就不管了,写代码时间多学习准备跳槽挺好的
    akira
        35
    akira  
       81 天前
    你这是生怕别人不好脱裤么。。这下好了,直接 api 就能获取到数据了,渗透都不用了
    lecher
        36
    lecher  
       81 天前
    缺一个 BFF 框架,展示数据不能受限于后端开发人员的约束。
    https://maguangguang.xyz/backend-for-frontend
    https://maguangguang.xyz/bff-governance

    看看之前 v 站用户的分享
    gogogo1203
        37
    gogogo1203  
       81 天前
    golang 的解决方案是 应用层 和 数据层 的 user 写成两个 struct, 进出应用层用 user, 数据层出来要强制转化格式 。
    刚开始挺麻烦的, 做习惯了就好了

    ```
    package user
    type User struct {
    ID string `json:"id,omitempty"`
    Username string `json:"username"`
    Email string `json:"email"`
    Roles []string `json:"roles,omitempty"`
    PasswordHash []byte `json:"-"`
    }

    package db
    type User struct {
    ID string `db:"user_id"`
    Username string `db:"username"`
    Email string `db:"email"`
    Roles pq.StringArray `db:"roles"`
    PasswordHash []byte `db:"password_hash"`
    ....
    }

    ```
    TUNGH
        38
    TUNGH  
       81 天前
    作为后端开发,给前端的每一个接口几乎都重写了 VO,你们后端这样写,不但懒,而且蠢.
    jhdxr
        39
    jhdxr  
       81 天前
    如果本身接口就是简单的 CRUD ,为啥我觉得除了潜在的安全风险(敏感字段,例如密码之类的。但这也只要配置一个黑名单)以外这么做没啥问题?除了浪费了一点流量。上面还有人提字段名泄露啥的,改个名掩耳盗铃吗?又是真有一个注入点,想要拖数据的还需要在乎你有没有泄露字段?现在都是自动化工具了。
    mu666
        40
    mu666  
       81 天前
    @akira api 本来不就是获取数据的吗?这个应该要怎么改?
    darkengine
        41
    darkengine  
       81 天前
    @rabbbit 0 和 1 还算好的,以前接过一个屎山,后端返回来的布尔值是 1 和 2 。。。。。。。
    jorneyr
        42
    jorneyr  
       81 天前
    @yedanten 你这是想给数据库字段加密么。
    Qseven
        43
    Qseven  
       81 天前
    对这种一个实体从底贯穿到外的做法,十分鄙视,写什么代码,麻烦回去种田。
    seakingii
        44
    seakingii  
       81 天前
    建 VO 是好习惯

    不过为了能早点下班的话懒点也能理解...
    yyf1234
        45
    yyf1234  
       81 天前 via iPhone   ❤️ 2
    艸,以为看到我公司的代码了
    labulaka521
        46
    labulaka521  
       81 天前
    labulaka521
        47
    labulaka521  
       81 天前
    @darkengine 哈哈 我们用的 grpc + golang 布尔值在 proto 里就是定义成 1 或 2
    Dragonphy
        48
    Dragonphy  
       81 天前
    我竟然觉得没什么问题[假笑],不想要无关字段可以针对不同的需求建立 VO ,而且前端取模也没啥大不了的吧,我们的后端我让直接写 SQL[二哈]
    sampeng
        49
    sampeng  
       81 天前   ❤️ 1
    这种后端写什么程序,回家种田吧。

    先不说偷懒不偷懒,不摸鱼的员工不是好员工。

    单说反正机器流量钱不是他出,按 LZ 的这个例子,最少流量费用要多出 50%出来。服务端 GZIP 需要 cpu 。cpu 利用率多出 50%。客户端需要解压缩,需要 get body ,客户端也是要损失一部分损耗在里面。

    你们后端 leader 是吃屎的?这都不管?那管啥?
    rabbbit
        50
    rabbbit  
       81 天前
    @sampeng
    息怒,这都不算啥,你还没见过批量删除让前端自己写循环发请求挨个删的。
    dengshen
        51
    dengshen  
       81 天前 via iPhone
    @TUNGH 做 node 不仅要重写 vo 还要重写 dto 日了狗了
    ccppgo
        52
    ccppgo  
       81 天前
    既然是 java 。。属性为 null 这种东西用 jackson 处理一下不就好了么
    asfas1246
        53
    asfas1246  
       81 天前
    我一个接口,返回了 45 万个字符。其中需要的,10%都不到。
    aliveyang
        54
    aliveyang  
       81 天前
    什么阶段干什么事,不怎么重要的项目套模板没什么不好的
    Cielsky
        55
    Cielsky  
       81 天前
    @mokevip 那你跟后端管理说不就完事了,然后保留聊天记录方便甩锅即可
    XCFOX
        56
    XCFOX  
       81 天前
    这时候就体现出 GraphQL 的好处了,后端还是直接抛从数据库里取出来的对象,前端需要什么按需取就行了
    PopRain
        57
    PopRain  
       81 天前
    楼上说的一个对象用到底就鄙视不能认同, 大部分企业应用有复杂的逻辑和界面,每个界面(前端)对应一个 VO , 那管理起来太复杂了。。。。
    unnamedhao
        58
    unnamedhao  
       81 天前
    前后端接口规则咋定,一般看谁能打过谁
    morize
        59
    morize  
       81 天前
    作为前端,我觉得返回 null 没什么问题,做数据防御是基本的好吧。可选链 ?. 又不麻烦。
    多余的字段怎么说呢,难道来需求了前端后端一起改吗,太麻烦了吧。
    觉得不好自己再 format 一次咯,要是你习惯把接口的数据直接抛到 view 层当我没说。
    lanlanye
        60
    lanlanye  
       81 天前
    暴露了表结构可能是一个问题,另外如果冗余数据的内容非常多导致传输受到影响也不好。
    除此之外其实没什么太大的问题,而且我个人的看法是少量的计算和格式转换交给前端做更好,毕竟前端的计算压力分散在每一个客户端(浏览器)上,而后端处理则是一台服务器处理所有请求需要的数据,显然前端处理可以分散压力。

    当然实际项目中大部分人这么做是因为懒(摊手
    aababc
        61
    aababc  
       81 天前
    @labulaka521 卧槽,这么高级的吗?感觉这样会被人打死的!
    cjzlol
        62
    cjzlol  
       81 天前   ❤️ 2
    楼上那么多说暴漏表结构的,专门起个跟数据库里表字段不一致的 VO ?
    lower
        63
    lower  
       81 天前   ❤️ 3
    你实在看不起跟你协作的后端同事的话,就找他的 leader 或者老板来协调,在论坛来吐槽大可不必;
    聊天记录里对方也说了,你不方便处理他再给你写个接口……有什么毛病么?

    大家都是吃这碗饭的,想挑毛病怎么都能挑几条;
    前后端分离的模式本身就会引入一些新的问题,不可能有完美的方案能解决所有可能的隐患;

    工作中我最害怕的就是遇上那种事儿特别多,总是坚持自己想法的同事或者领导,口一张就要让别人怎么怎么配合他工作,理由也是一大堆,每次都非要争赢,完全不管别人的情况……
    😔
    labulaka521
        64
    labulaka521  
       81 天前 via iPhone
    @aababc 因为 golang 里的默认值问题只能这么搞了 目前还没被打 因为不是我设计的😆
    marcojbk
        65
    marcojbk  
       81 天前 via iPhone   ❤️ 1
    那我说个相反的,我司前端从来不处理任何数据,全都靠后端我给他处理好,他只负责展示。
    FawkesV
        66
    FawkesV  
       81 天前
    就是偷懒而已. 正常来写要写 vo 类映射的.
    changdy
        67
    changdy  
       81 天前
    哈哈哈 ..前后端 势如水火
    你说后端菜 ,后端说你娱乐圈 ..
    你说后端 null 全字段 ,后端说你 不会用 GraphQL ...

    老老实实搬砖吧... 不要把公司的压迫 转移成了 前后端的撕逼 ....
    masterclock
        68
    masterclock  
       81 天前   ❤️ 1
    null 是 null ,不存在是不存在,是什么就返回什么

    取模 10 这种操作让后端做??你要取模 10 ,另一个前端要取模 11 ,怎么处理?
    zarvin
        69
    zarvin  
       81 天前
    无解,后端不做,肯定就是前端做,工作量转移而已
    Felldeadbird
        70
    Felldeadbird  
       81 天前   ❤️ 1
    后端来说一下,这种低风险的字段映射一般情况可以忽略安全考量。全字段输出更加省事。后端不知道前端要什么数据啊。没有明确规范下,非敏感库全字段输出节省了前端沟通成本。

    就算你做了字段处理,人总会犯错的。如果觉得敏感应该找后端和负责人来处理。
    wolfie
        71
    wolfie  
       81 天前
    OP 就是平时接触到的高血压前端
    itechnology
        72
    itechnology  
       81 天前   ❤️ 1
    作为一个后端,我觉得他们这样做完全没问题,无非就是有点不规范而已。
    wonderfulcxm
        73
    wonderfulcxm  
       81 天前 via iPhone
    laravel Eloquent ORM 可以很方便设置隐藏、显示哪些字段。
    Vitta
        74
    Vitta  
       81 天前   ❤️ 1
    《用你写的接口我都不如直接用云数据库》
    knightdf
        75
    knightdf  
       81 天前
    返回给前端的到底是 VO 还是 DTO ?怎么看楼上两种叫法都有?
    v2orz
        76
    v2orz  
       81 天前
    不好说对错,这种事,关系好的商量一下就好,早点搞完早点跟前端兄弟吃火锅去
    不是所有系统都要考虑什么多传几个字符、gzip 压缩这些的,具体场景具体分析
    人家就要快,就要便宜,给你 DeadLine ,只能提前不能推迟

    不过我也遇到过,字段为 1 ,显示成第 1 行,都要后端给他转换好的人
    RealJacob
        77
    RealJacob  
       81 天前
    有时候多带一些数据是正常的,但是该处理的数据还是要处理好就可以了。别就查个表什么都不处理
    p1gd0g
        78
    p1gd0g  
       81 天前
    我做全栈的时间就爱这么干,省事,还能给服务器减压
    keepeye
        79
    keepeye  
       81 天前
    哈哈 搞前端的火气这么大吗?来哥请你去大保健消消火,298 套餐怎么样
    l00t
        80
    l00t  
       81 天前
    无非是懒了点,又不是不能用…… 你要说这是不是一个好的设计,那肯定不是。但也不算什么大事,写程序还是要提高自己的适应性,你总会遇到各种烂代码烂接口烂项目的。
    yor1g
        81
    yor1g  
       81 天前
    有没有接口文档 , 有就他不对, 没有的话没啥问题. 后端都想直接给你一个方法, 自己写 sql 好了, 想要啥字段自己查
    l00t
        82
    l00t  
       81 天前   ❤️ 1
    @sampeng 你要考虑这么极端那解释性语言可以都直接下岗了。HTTP 本身效率也不高,可以废了。
    zealinux
        83
    zealinux  
       81 天前   ❤️ 1
    建议用 GraphQL
    lscexpress
        84
    lscexpress  
       81 天前
    @asfas1246 啥接口啊?吹牛有点过了吧
    sampeng
        85
    sampeng  
       81 天前
    @l00t 编程语言是合理的浪费,并不极端。。lz 这种情况是不合理的。。不能偷换概念
    daimubai
        86
    daimubai  
       81 天前
    他喜欢你
    HeHeDaGe
        87
    HeHeDaGe  
       81 天前
    yml 配置行就行了

    jackson:
    default-property-inclusion: non_null
    akira
        88
    akira  
       81 天前
    @mu666 不一样的,应该尽量只返回客户端需要展示的数据,遵循最小化原则。 同时数据里面的各种 id 应该尽量不可枚举, 特别是规律性的自增 id 等,均不应该返回给前端,不然非常容易出现平权漏洞。另外各种敏感数据以及隐私数据就更加要小心了,国内的话还好,没啥人较真,国外爆一个漏洞,公司直接可以关门了。

    最后,这个后端看起来似乎是直接 select * ,然后就全部返回了,这种技术债迟早要还的。
    keeguai
        89
    keeguai  
       81 天前
    交给前端做也能说得通,毕竟后端更多考虑通用性,给你这个功能取模 10 了,其他功能调用要不要去掉?
    另外这种计算处理最好还是交给前端,前端计算压力是客户浏览器的,放在后端,就是公司服务器承担了。
    至于返回 null 值,后端可以过滤,甚至可以自动过滤,JSON 转一下就没了,但是有时候 null 值也是有意义的。
    你这个问题是你们公司前后端协同问题,是接口协议谁来定?是前后端谁来决定业务逻辑的问题。
    跟技术没关系,是个管理问题。
    libook
        90
    libook  
       81 天前
    都是管理上的问题,前后端应该在工作内容方面有个清晰的界限。
    potatowish
        91
    potatowish  
       81 天前 via iPhone
    个人项目倾向于只返回需要的字段。公司项目那就另说了,只要管理没严格要求,那就怎么方便怎么来,毕竟工期在那摆着呢。你在和后端为了这些字段该不该一起返回争的面红耳赤的时候,隔壁组的兄弟已经下班了~
    falcon05
        92
    falcon05  
       81 天前
    那肯定不对的啊,请求某个用户信息接口,把密码也暴露出来怎么行。
    ZSeptember
        93
    ZSeptember  
       81 天前
    看风格,RESTful 风格的 API 关注的是业务模型,返回的都是模型所有字段,而不是根据前端需要返回字段。
    当然,你们现在的风格就是 RPC 风格,后端应该只返回前端需要的字段就可以了
    vyronlee
        94
    vyronlee  
       81 天前 via iPhone
    经典语句来了,”又不是不能用”。API 设计者不从使用方考虑便利性,而从自身实现来决定 API 长啥样,这种 API 就是不及格的。
    Bingchunmoli
        95
    Bingchunmoli  
       81 天前
    @akira 我们主键 ID 是过滤的其他以为都是业务需要,所以也会返回,无非是这个接口与另一个接口的问题。
    Bingchunmoli
        96
    Bingchunmoli  
       81 天前
    前端计算之前也有人讨论过, 因为比如 app 要展示分,PC 展示元,那么后端是两个数据还是说我一个数据,前端处理好。 显而易见面向数据通用性更广,但是面向业务(通常都是面向业务开发),两个字段更方便,前端不需要做适配
    liuidetmks
        97
    liuidetmks  
       80 天前
    直接找老板谈,
    "你这有这样的员工,我活没法干了, 我还是他,选一个吧"
    masterclock
        98
    masterclock  
       80 天前
    第一天:App 显示 分,后端返回 100
    第二天:App 显示 元,后端返回 1

    于是未更新的 App 上全部都显示 1 分
    jhdxr
        99
    jhdxr  
       80 天前   ❤️ 2
    @akira 理论上是这样,但是实操是另外一回事。你数据库表设计范式全遵守了?

    平权漏洞和是否返回给前端没有关系,而是应该做好权限校验。指望通过不告诉别人来解决漏洞,就好比“自研”各种加密算法,指望通过算法的保密来保证安全性。

    别总觉得国外的月亮圆,信用卡数据这么多公司泄露了,哪个关门了?

    另外举一个具体的例子,获取用户信息。一个常见的,也是许多人口中偷懒的例子是直接一个 select * (当然,过滤掉诸如密码之类的敏感字段)作为一个 API ,前端自己去选取需要的信息。另外一个是根据每一个业务场景分别去做一个 API 。当然,还有 graphql 这种解决方案。我并不认为第一种方案一定是不好的。
    wolfie
        100
    wolfie  
       80 天前
    这种后端建议直接开除,多反了几个 null 搞得前端直接宕机不会写代码了。
    1  2  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4243 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 36ms · UTC 05:59 · PVG 13:59 · LAX 22:59 · JFK 01:59
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.