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

[witcat]

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

[darkengine]

@baleeny 理解他的意思，其实是他们的后端觉得用 name 没问题，OP 觉得不规范。就像“我们的后端要求所有请求都用 POST”一样。😂

[jstony]

@baleeny +1 ，前提是 op 头够铁，能确保 name 字段唯一且不会变更，有一天产品经理说 name 要可以修改，你一定要坚持住不同意，就是老板来了，捅破天 name 也不能改😄，老板问为什么不能改，心里默默骂自己当初为什么那么中二。

[Esen]

反正能用就行，我们主打的就是一个怎么方便怎么来，前后端和气

[Chad0000]

@darkengine
UUID 会导致多一次查询，这也是我之前的方案。后来我看到 HashID 后就改进了。

[chuck1in]

前端要用那个 id 来做那种循环组件的 index 的。

[witcat]

@jstony 我自己的 side project 啊 前后端都自己写😂 公司的项目谁还费劲去较真

[jstony]

@witcat 那你赢了，爱咋写咋写，你的地盘你做主😄

[witcat]

@jstony 你也太会分析了吧😅

[fiypig]

id 比字符串效率多了

[tool2d]

我专门写了一个基于字符串 key 的搜索引擎，好处是对于只读数据筛查效率很高。

坏处是对于经常变动的数据集，老是重建索引就比较麻烦了。

[blackkkk]

喜欢怎么用就怎么用，不行推了重来，主打的就是能用就行。
如果考虑可扩展性，考虑规范性，那该 id 就 id ，而且业务 id 和自增 id 一般都会分开的，不然哪天自增最大值了怎么办，发现数据中自增不连续怎么办等等。
凡是列表理论上都应该有唯一标识表示这行数据再整个列表中的唯一性。有时候业务还能跟你纠结这条数据第一次在第一行，第二次怎么到第二行去了等等奇奇怪怪的需求

[tomkliyes]

name 可以保证不重复的话，替代 id 是没有问题的。一般来说 api 也不应该把原始自增 id 暴露出来，容易让人通过 id 猜到数据量级，比如新注册一个账号，返回用户 id=201 ，可以推测系统目前有 201 个用户。

[brader]

我觉得这不是你关心的，反正咱只要按接口要求对接，查不查的了是后端的事，接口响应慢的话，找他就对了

[chf007]

只要能实现需求想返回啥就返回啥，只要你能 hold 住

[JarvisTang]

完全可以，我就是这样干的。

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

原因，不想让人知道数据库真实的记录数量。

[1017nano]

能给 id 就 id ，万一以后 name 包含特殊字符什么的，要传递的话还得特殊考虑，id 够稳定。