我应该在我的公共 API 中使用 UUID 来获取资源吗？

Posted 2023-03-24

【中文标题】我应该在我的公共 API 中使用 UUID 来获取资源吗？

【英文标题】：Should I use UUIDs for resources in my public API?

【发布时间】：2011-08-18 22:03:31

【问题描述】：

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

我对这种方法很满意，但我想知道为什么我找不到任何来自大型 SaaS/托管玩家的 API 可以做到这一点？例如：

Shopify：9 digit numbers Twilio：34 character strings 推特：20+ digit numbers AMEE：12 character A-Z0-9

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

【问题讨论】：

为一个好问题点赞！结果如何？您是否将它们存储在单独的列中？

嗨大卫，是的，最后我使用了 UUID 并将它们存储在单独的列中！

我正在做同样的事情

AMEE 链接已失效，但现在可以是 found here

【参考方案1】：

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

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

继续使用 UUID。

【讨论】：

谢谢布赖恩，是的，我将继续使用 UUID

【参考方案2】：

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

使用 UUID 作为您的数据库主键，但可能更多 computationally expensive than using Long

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

在您的数据库表中创建一个备用键列以保存 de UUID 值。

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

【讨论】：

谢谢亚历山德罗！我最终选择了选项 3。