我正在构建一个SaaS应用程序，并希望公开与我当前数据存储实现无关的资源ID（Postgres自动增量ID）。这些Stack Overflow帖子（one two）表明创建本地唯一ID非常困难，而且我也可以使用UUID，这些UUID当然可以用几乎任何语言轻松安全地生成。
我对这种方法感到满意，但我想知道为什么我找不到大型SaaS /托管播放器的任何API呢？例如：
所以基本上没有人似乎使用UUID。有没有理由 - 这里没有发明，更聪明的内部ID算法或其他什么？在我的情况下，在没有任何内部算法的情况下，使用UUID最合理吗？
答案 0 :(得分：34)
您列出的其他供应商可能拥有自己的ID或散列方案，以允许他们在内部使用类似于UUID的内容时公开较小的数字。但最后，必须提出一个问题：只要您的URI旨在被代码（API客户端）而不是人类使用，为什么它会重要？
不要被这些供应商所做的事情吓到太多。无法保证（a）他们正在做“正确”的事情，（b）他们的需求与您的需求相同。
继续使用UUID。
答案 1 :(得分：9)
我认为您可以考虑以下四个主要选项：
使用UUID作为数据库主键，但可能更多computationally expensive than using Long
创建一个UUID到Long映射层，这样就可以发布REST资源，但使用Long PK维护一个干净的数据库结构
在数据库表中创建一个Alternate Key列，以保存de UUID值。
您可以使用UUID代替使用UUID，使用每个客户的自定义种子和原始PK即时生成加密ID。这种方法会增加执行开销，但在某些情况下可能会很有趣。客户必须始终使用加密数据，因为他们永远无法访问种子或算法。