使用数据库表的ID作为外部API标识符是一个不好的想法吗？

Question

我们正在设计一个带有外部API的HTTP服务，需要存储一些项目，外部API使用者可能需要稍后检索。所有内容都存储在一个名为foos的表中，目前的计划是只使用表的主ID键作为外部唯一标识符。我的直觉告诉我这是糟糕的设计，但我无法有效地阐述原因，部分原因是我不能表达清楚。

到目前为止，我能想到的唯一缺点如下：

• 如果我们想要更改模式怎么办？我们必须重新填充所有内容，确保它们的ID保持完好无损，或在移动期间实施另一个唯一标识符列
• 轻微（？）安全风险（我知道，安全性通过隐蔽性不安全等等）

是否存在其他重大缺点，还是我只是多虑了？还希望提供一些关于此问题的已发布文章的链接！

- Suan

Answer 1

我认为如果你的数据库已经被锁定，那么以下情况就不重要，除非：

• 共享API密钥将导致用户信息的CIA丢失。
• 你让用户轻松调用API而没有二级身份验证。

你应该已经意识到，采取防范SQL注入措施将防止任何人利用此信息，但是了解索引范围可能意味着某人将知道一个索引范围中比实际少1或多1的键是可用于访问你的API的有形密钥。

---

例如:

如果您可以通过URL访问API而无需登录，则使用索引范围是不好的。
http://mysite.com?APIkey=145
如果我知道我的密钥是145，那么144和146可能也可以用来进行调用。

使用GUID方案是处理这个问题的方法，但是您需要做出其他牺牲：
ID（索引）：145
ID（GUID）：C87FC84A-EE47-47EE-842C-29E969AC5131

---

最后，你可以添加另一列来保存随机哈希作为唯一的API密钥，就像你说的那样：
ID（哈希）：da39a3ee5e6b4b0d3255bfef95601890afd80709

- Dan Kanze

Answer 2

这是完全安全的。这些ID将随着其他数据一起备份并恢复，因此没有任何问题。我也想不到任何安全问题。是否是糟糕的设计取决于口味。

IIRC eBay和PayPal API就是这样工作的，但我无法引用参考资料。

- Philip Sheard

Answer 3

我同意你的第一个观点：

如果由于任何原因您最终更改了模式，您的服务应该抽象出物理更改。保留旧键会使这变得非常困难....

- Shlomo