为数据库复合键生成唯一API资源标识符

嗨，Jason，这个问题我之前帮不少开发者梳理过，咱们一步步拆解来聊～

首先，针对你的场景（房间实体用room-id+building-id复合键，其中building-id是外键），生成API唯一标识符主要有几种实用方案，各有优劣，咱们逐个分析：

方案1：直接复用复合键（拼接或分层路径） #

这是最直接的方式，不需要额外存储：

• 要么把两个键用不会出现在字段中的分隔符拼接成一个字符串，比如{room-id}-{building-id}（比如101-5代表5号楼101室），或者用URL安全的分隔符比如%3A（冒号的URL编码）避免冲突；
• 要么遵循RESTful资源层级，把复合键拆成路径参数，比如/api/buildings/{building-id}/rooms/{room-id}，这种方式更清晰，也符合API设计的最佳实践。

优点：零额外存储成本，能直接从标识符反向解析出原复合键，开发成本极低。
缺点：如果复合键的任一字段发生变更（比如building-id调整），API资源的标识符也会跟着变，可能导致客户端旧请求失效；另外如果字段本身包含分隔符，需要提前做转义处理。

方案2：新增UUID字段作为API标识符 #

给你的room实体新增一个uuid字段，在数据插入时生成唯一UUID（可以用数据库内置函数，比如PostgreSQL的uuid_generate_v4()，或者应用层生成），API对外统一用这个UUID作为资源标识，比如/api/rooms/{uuid}。

优点：API资源地址完全和业务复合键解耦，就算room-id或building-id变更，UUID可以保持不变，对外API的稳定性极强；URL更简洁美观，也避免了复合键拼接的冲突问题。
缺点：需要额外存储一个UUID字段，且无法直接从UUID反推出原复合键（不过可以在API响应体里返回room-id和building-id给客户端）。

方案3：哈希复合键生成短标识符 #

把room-id和building-id拼接后做哈希运算（比如SHA-256取前16位，或者用MD5，不过SHA更安全），生成一个短的唯一字符串作为API标识。

优点：不需要额外存储，生成的标识符比拼接字符串更短；
缺点：哈希是单向运算，无法反推出原复合键；虽然哈希碰撞概率极低，但理论上存在风险，需要确保哈希后的长度足够（比如至少128位）；和拼接方案一样，复合键变更会导致标识符失效。

关于复合键变更的处理建议 #

首先要强调：尽量避免复合键变更，尤其是building-id作为外键，变更会牵连大量关联数据，业务上应该尽量保证这类标识的稳定性。如果真的遇到必须变更的场景：

• 用UUID方案：完全不需要调整API，只在数据库更新room-id/building-id字段即可，客户端访问原UUID仍能获取到更新后的资源，体验最佳；
• 用拼接/哈希方案：需要在API层做301永久重定向，把旧标识符的请求导向新的标识符；同时可以在数据库保留旧键的映射关系一段时间，或者在响应中返回新的标识符，提示客户端更新缓存的地址。

最终推荐 #

如果你的API稳定性要求较高（比如客户端会长期缓存资源地址），优先选UUID方案，它彻底解决了复合键变更带来的API兼容性问题，开发和维护成本也很低；如果业务上能保证复合键几乎不会变更，且不想新增字段，那用拼接或分层路径的方案最省事。

备注：内容来源于stack exchange，提问作者Jason