我应该在公共API中使用UUID作为资源吗？

我正在构build一个SaaS应用程序，并希望公开与当前数据存储实现（Postgres自动递增ID）无关的资源的ID。 这些堆栈溢出的post（ 一 两个 ）表明，创build本地唯一的ID是很难的，我不如使用UUID，这当然很容易和安全地生成几乎任何语言。

我对这种方法很满意，但是我想知道为什么我找不到来自大型SaaS /托pipe公司的任何API。 例如：

• Shopify： 9位数字
• Twilio： 34个字符的string
• Twitter： 20+位数字
• AMEE： 12个字符A-Z0-9

所以基本上没有人使用UUID。 有没有这个原因 – 这里没有发明，更聪明的内部身份证algorithm或其他？ 在我的情况下，在没有任何内部algorithm的情况下，使用UUID最合适吗？

Answer 1

您列出的其他供应商有可能拥有自己的ID或哈希scheme，以允许他们在内部使用更类似于UUID的内容时显示较小的数字。 但是最后，必须提出这个问题：只要你的URI是被代码（API客户端）而不是人类消费的，为什么这么重要呢？

别被那些供应商所做的事吓到了。 （a）他们正在做“正确的”事情，（b）他们的需求和你的需求是一样的。

继续使用UUID。

Answer 2

我想你可能会考虑这里的四个主要选项：

1. 使用UUID作为您的数据库主键，但它可能比使用Long计算更昂贵

2. 创build一个UUID到Long映射层，这样你就可以发布你的REST资源，但是使用Long PK维护一个干净的数据库结构

3. 在你的数据库表中创build一个备用密钥列以保存de UUID值。

4. 而不是使用UUID，您可以使用encryption标识，使用每个客户和原始PK的自定义种子即时生成。 这种方法会带来更多的执行开销，但在某些情况下可能会很有趣。 客户将不得不始终使用encryption的数据，因为他们永远不能访问种子或algorithm。