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

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

我对这种方法感到满意，但我想知道为什么找不到大型SaaS /托管播放器中的任何API都这样做吗？例如：

• Shopify：9位数字
• Twilio：34个字符串
• Twitter：20位数以上的数字
• AMEE：12个字符A-Z0-9

因此，基本上没有人似乎使用UUID。这是否有原因-不是在这里发明的，更聪明的内部ID算法还是其他？就我而言，在没有任何内部算法的情况下，使用UUID是否最有意义？

您列出的那些其他供应商可能有自己的ID或哈希方案，以允许他们在内部使用更类似于UUID的同时公开较小的数字。但是最后，必须提出一个问题：只要您的URI是由代码（API客户端）而非人类使用的，那为什么重要呢？

别被那些供应商的所作所为吓坏了。无法保证（a）他们在做“正确的”事情，并且（b）他们的需求与您的需求相同。

继续并使用UUID。

我认为您可以在这里考虑四个主要选项：

1. 使用UUID作为数据库的主键，但是与使用Long相比，它在计算上可能会更昂贵

2. 创建一个UUID到Long映射层，通过这种方式，您可以发布REST资源，但使用Long PK维护干净的数据库结构

3. 在数据库表中创建一个Alternate Key列，以保存de UUID值。

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