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

Question

我正在构建一个SaaS应用程序，并希望公开与当前数据存储实现（Postgres自动增量ID）无关的资源的ID。这些堆栈溢出帖子（onetwo）表明创建本地唯一ID很难，我不如使用UUID，这些UUID当然可以在几乎任何语言中轻松安全地生成。

我对这种方法感到满意，但我想知道为什么我无法从大型SaaS /托管玩家那里找到任何类似的API？例如：

• Shopify：9 digit numbers
• Twilio：34 character strings
• 的Twitter：20+ digit numbers
• AMEE：12 character A-Z0-9

所以基本上没人似乎使用的UUID。有没有这个原因 - 这里没有发明，更聪明的内部ID算法或其他东西？在我的情况下，在没有任何内部算法的情况下，使用UUID最合适吗？

Answer 1

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

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

继续并使用UUID。

Answer 2

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

1. 使用UUID作为数据库主键，但它可能是更computationally expensive than using Long

2. 创建UUID龙映射层，通过这种方式，您可以发布您的REST资源，但使用Long PK维护一个干净的数据库结构。为了保存de UUID值，在您的数据库表中创建一个Alternate Key列。

3. 代替使用UUID，您可以使用每个客户和原始PK的自定义种子实时生成加密ID。这种方法会产生更多的执行开销，但在某些情况下会很有趣。客户必须始终使用加密的数据，因为他们永远无法访问种子或算法。