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

列表 api 不返回 id 给前端可以吗?

  •  
  •   witcat · 2023-07-11 23:40:25 +08:00 · 3797 次点击
    这是一个创建于 373 天前的主题,其中的信息可能已经有所发展或是发生改变。

    数据表里 id (单库,自增数字)和 name(长度 10 个以内的英文字符串)是唯一的。
    后端不返回 id ,接口都让前端用 name 字符串获取数据,
    不是为了防采集。就是觉得很少见到用可读的字符串作为查询的条件,想问一下这样做会有什么问题吗?

    第 1 条附言  ·  2023-07-12 14:04:42 +08:00
    总和来看,目前的结论是可以的。
    只要 name 有 unique 约束
    自增 id 主要是为了提高一点点的性能。内部关系可以用 id 关联。
    但返回的数据和查询条件都只能通过 name ,要问为啥的话,可能只是因为 1.我这个案例比较特殊 name 确实不会重复而且是可读的 2.如果用可读的字符串来查,不知道怎么说,可能更自然吧,个人喜好。3.既然可以用 name 查,就没必要用 id 查了,防止出现查询条件不统一的情况。4.如果我把 api 公开,我希望精简易懂。没有多余的字段,如果 name 可以替代 id ,那么 id 是多余的。
    webfamer
        1
    webfamer  
       2023-07-11 23:43:11 +08:00
    id 唯一,名字会重复
    witcat
        2
    witcat  
    OP
       2023-07-11 23:43:35 +08:00
    @webfamer 不重复的可以吗
    pengtdyd
        3
    pengtdyd  
       2023-07-11 23:46:51 +08:00
    可以
    zhengjian
        4
    zhengjian  
       2023-07-11 23:55:50 +08:00   ❤️ 1
    可以,另外可以试试 https://hashids.org/ 把 id 加密一下
    witcat
        5
    witcat  
    OP
       2023-07-11 23:58:52 +08:00
    @zhengjian 如果完全不返回任何 id 给前端 还有必要加密吗
    mineralsalt
        6
    mineralsalt  
       2023-07-12 00:04:20 +08:00   ❤️ 4
    不可以, 一般默认 name 是变动的, 是一种不确定的值, id 是不变的, 用 id 查更可靠, 其次 id 查询速度现对于字符串的 name 更快, 要养成良好的编程习惯, 一般前后端传值都是用 id, 又没特殊需求, 就遵循默认不好么, 干嘛特立独行, 当然业务需求非用 name 当然也没问题
    b1t
        7
    b1t  
       2023-07-12 00:19:42 +08:00
    能用,但这种方式不可取,反驳的槽点很多
    witcat
        8
    witcat  
    OP
       2023-07-12 00:22:06 +08:00
    @mineralsalt 谢谢,我想延伸再问一下,假设 name 大多数时候创建了就不会变,但如果变了,会有什么后果吗?
    我目前能想到的就是用户用浏览器把这个页面收藏了,后面再访问数据就不见了。
    因为我也好奇,微博、推特这些网站也是用 用户自定义的 id 定位一个用户,但都不能修改。还有什么其他原因吗?
    witcat
        9
    witcat  
    OP
       2023-07-12 00:23:09 +08:00
    @b1t 有时间就告诉我几个槽点吧,单纯就是想长长知识。
    shakukansp
        10
    shakukansp  
       2023-07-12 00:29:12 +08:00
    前端框架比如 vue react 渲染表格都需要给每一个表格项绑定一个唯一的 key ,用来复用元素或者检测变更

    你不给前端就要自己弄一套自增的 id 来标记,为啥不直接给呢?
    witcat
        11
    witcat  
    OP
       2023-07-12 00:33:06 +08:00
    @shakukansp name 可以作为 key 啊
    tangtj
        12
    tangtj  
       2023-07-12 00:41:04 +08:00   ❤️ 1
    两个用户 a 和 b name 在短时间内 name 都改变了, b 用户改成 a 用户之前的用户名 . b 是否会查到 a 的数据
    witcat
        13
    witcat  
    OP
       2023-07-12 00:42:49 +08:00
    @tangtj 对哦 是防止被冒充的风险
    shakukansp
        14
    shakukansp  
       2023-07-12 00:42:49 +08:00
    @witcat 看了下,name 不重复的话可以
    witcat
        15
    witcat  
    OP
       2023-07-12 00:43:21 +08:00
    @shakukansp #14 🤝
    moonrailgun
        16
    moonrailgun  
       2023-07-12 00:51:50 +08:00   ❤️ 1
    第一,id 可以作为后续操作的唯一标识,比如你要点击到某一条记录肯定不能是第几条或者某个 name
    第二,id 可以作为前端缓存的唯一标识,当然如果不做缓存当我没说
    第三,如果这个列表是动态更新的,id 可以优化前端渲染性能(在 mvvm 框架)
    第四,代码洁癖,一条记录一定要有一个唯一 key ,不然纯粹靠数组会不放心,当然这个洁癖可以没有
    chendy
        17
    chendy  
       2023-07-12 08:24:27 +08:00
    有 id 就老老实实用 id ,id 用到系统下线公司关门都不会重复
    name 今天不重复说不定以后会重复,或者日后有其他业务规则上来需要 name + 其他某些字段才能确定是哪一条数据就要坐牢了
    Dragonphy
        18
    Dragonphy  
       2023-07-12 08:43:44 +08:00
    name 可能会有需求变动要求可更改,不如用一个 nanoid 字段,但这和 id 其实没啥区别
    darkengine
        19
    darkengine  
       2023-07-12 08:53:01 +08:00
    把自增 id 暴露出来其实有一定风险的,例如可以通过 id 的值判断你们业务大概到了什么量级。
    MEIerer
        20
    MEIerer  
       2023-07-12 09:02:52 +08:00 via Android
    ......
    Laysan
        21
    Laysan  
       2023-07-12 09:14:24 +08:00
    把业务 ID 和数据库自增 ID 区分开
    LeegoYih
        22
    LeegoYih  
       2023-07-12 09:24:04 +08:00
    “怕被爬数据而不返回 id”,我只能说是后端开发能力有问题。
    即便是自增的也不会有这种问题,资源权限数据权限基本上能覆盖 99%。
    Tyaqing
        23
    Tyaqing  
       2023-07-12 09:37:48 +08:00
    雪花 id,id 中间层 hash 转换都能解决这个问题
    dode
        24
    dode  
       2023-07-12 09:41:33 +08:00
    前端篡改了 id 还要后台校验
    EthanLiu1993
        25
    EthanLiu1993  
       2023-07-12 09:44:12 +08:00
    看需求吧,都唯一的用哪个都行
    InDom
        26
    InDom  
       2023-07-12 09:44:40 +08:00   ❤️ 1
    不要用业务相关字段与代码强绑定。

    只要这个 name 是用户产生的,就一定不要在代码中作为关联使用。

    你可以不使用 id ,但必须再额外生成一个与用户无关,原则上用户也永远看不到的唯一字段。
    DoubleKing
        27
    DoubleKing  
       2023-07-12 09:49:06 +08:00
    不要用自增的 id ,也不要用 name 这个字段,即使你的 name 不会重复,这会在后期维护中造成不必要的误解
    me1onsoda
        28
    me1onsoda  
       2023-07-12 09:50:35 +08:00
    没搞懂。这么做跟直接用 id 有什么区别吗? id 天然唯一,name 你得分配一个 unique 索引,为什么要做这么多余的事情?
    gogo789
        29
    gogo789  
       2023-07-12 09:52:58 +08:00
    这个没啥不可以的,前端查询用的就是一个唯一标识,name 加一个唯一索引,保证不会重复。但是 name 这种二级索引需要回表,查询效率相对 id 的话会差一些。
    unco020511
        30
    unco020511  
       2023-07-12 10:02:27 +08:00
    只要是保证唯一,当然是可以的
    lisongeee
        31
    lisongeee  
       2023-07-12 10:04:05 +08:00
    如果使用 name 作为查询依据,比如之前的微博,你在微博发布动态去艾特别人,等到别人改名字之后你再点击动态里的艾特就显示查无此人,之后另一个用户改成你艾特的名字,你再点击动态里的艾特就跑到后者用户的主页了
    hundredFlowers
        32
    hundredFlowers  
       2023-07-12 10:05:39 +08:00
    可以,但没必要
    hu1e
        33
    hu1e  
       2023-07-12 10:07:47 +08:00
    不可以,后续你 name 不要编辑更新了吗?
    Chad0000
        34
    Chad0000  
       2023-07-12 10:12:56 +08:00
    @darkengine
    HashId 了解一下,而且这个还可以用来校验。比如把 Id+随机数一起生成 HashId ,根据 Id 加载数据,随机数跟相应的记录一起保存,那么就可以实现某种程度的验证,比如分享某条数据给别人。
    monologue520
        35
    monologue520  
       2023-07-12 10:59:15 +08:00
    按照一般约定, 列表需要提供 ID, 能减少很多问题
    suyuyu
        36
    suyuyu  
       2023-07-12 11:00:48 +08:00
    后续要删改根据什么字段呢?
    Huelse
        37
    Huelse  
       2023-07-12 11:03:41 +08:00
    下个需求就是根据 id 单独查询,总不会根据 name 来查吧?
    yxzblue
        38
    yxzblue  
       2023-07-12 11:05:24 +08:00
    可以,你是后端,想怎么返回都可以的,
    darkengine
        39
    darkengine  
       2023-07-12 11:09:41 +08:00
    @Chad0000 混淆 ID 有很多方案,例如每条记录带个 UUID ,前后端交互都根据 UUID 来操作也可以达到目的
    baleeny
        40
    baleeny  
       2023-07-12 11:13:52 +08:00
    楼上都误会楼主了,楼主说 name 大家以为是名字,楼主说 name 是唯一的,那不就是跟 uuid ,username 一个意思吗,可以作为查询条件,唯一了有啥不可以的
    darkengine
        41
    darkengine  
       2023-07-12 11:16:40 +08:00
    @baleeny 理解他的意思,其实是他们的后端觉得用 name 没问题,OP 觉得不规范。就像“我们的后端要求所有请求都用 POST”一样。😂
    jstony
        42
    jstony  
       2023-07-12 11:19:41 +08:00
    @baleeny +1 ,前提是 op 头够铁,能确保 name 字段唯一且不会变更,有一天产品经理说 name 要可以修改,你一定要坚持住不同意,就是老板来了,捅破天 name 也不能改😄,老板问为什么不能改,心里默默骂自己当初为什么那么中二。
    Esen
        43
    Esen  
       2023-07-12 11:21:56 +08:00
    反正能用就行,我们主打的就是一个怎么方便怎么来,前后端和气
    Chad0000
        44
    Chad0000  
       2023-07-12 11:22:33 +08:00
    @darkengine
    UUID 会导致多一次查询,这也是我之前的方案。后来我看到 HashID 后就改进了。
    chuck1in
        45
    chuck1in  
       2023-07-12 11:25:36 +08:00
    前端要用那个 id 来做那种循环组件的 index 的。
    witcat
        46
    witcat  
    OP
       2023-07-12 13:50:41 +08:00 via iPhone
    @jstony 我自己的 side project 啊 前后端都自己写😂 公司的项目谁还费劲去较真
    jstony
        47
    jstony  
       2023-07-12 13:57:23 +08:00
    @witcat 那你赢了,爱咋写咋写,你的地盘你做主😄
    witcat
        48
    witcat  
    OP
       2023-07-12 14:05:38 +08:00 via iPhone
    @jstony 你也太会分析了吧😅
    fiypig
        49
    fiypig  
       2023-07-12 14:07:36 +08:00
    id 比字符串效率多了
    tool2d
        50
    tool2d  
       2023-07-12 14:42:57 +08:00
    我专门写了一个基于字符串 key 的搜索引擎,好处是对于只读数据筛查效率很高。

    坏处是对于经常变动的数据集,老是重建索引就比较麻烦了。
    l502008310
        51
    l502008310  
       2023-07-12 14:54:49 +08:00
    喜欢怎么用就怎么用,不行推了重来,主打的就是能用就行。
    如果考虑可扩展性,考虑规范性,那该 id 就 id ,而且业务 id 和自增 id 一般都会分开的,不然哪天自增最大值了怎么办,发现数据中自增不连续怎么办等等。
    凡是列表理论上都应该有唯一标识表示这行数据再整个列表中的唯一性。有时候业务还能跟你纠结这条数据第一次在第一行,第二次怎么到第二行去了等等奇奇怪怪的需求
    tomkliyes
        52
    tomkliyes  
       2023-07-12 14:56:36 +08:00
    name 可以保证不重复的话,替代 id 是没有问题的。一般来说 api 也不应该把原始自增 id 暴露出来,容易让人通过 id 猜到数据量级,比如新注册一个账号,返回用户 id=201 ,可以推测系统目前有 201 个用户。
    brader
        53
    brader  
       2023-07-12 15:04:28 +08:00
    我觉得这不是你关心的,反正咱只要按接口要求对接,查不查的了是后端的事,接口响应慢的话,找他就对了
    chf007
        54
    chf007  
       2023-07-12 15:10:37 +08:00
    只要能实现需求想返回啥就返回啥,只要你能 hold 住
    JarvisTang
        55
    JarvisTang  
       2023-07-12 15:46:22 +08:00
    完全可以,我就是这样干的。

    https://docs.fresns.cn/api/data-structure.html
    用户、小组、话题、帖子、评论,分别是 uid, gid, hid, pid, cid
    全部是随机生成的字符串,唯一值,作为前端 ID/Key 使用。

    原因,不想让人知道数据库真实的记录数量。
    1017nano
        56
    1017nano  
       2023-07-12 16:27:16 +08:00
    能给 id 就 id ,万一以后 name 包含特殊字符什么的,要传递的话还得特殊考虑,id 够稳定。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2476 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 12:32 · PVG 20:32 · LAX 05:32 · JFK 08:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.