使用数据库表的ID作为外部API标识符是一个坏主意吗？

Question

我们正在设计带有外部API的HTTP服务，该服务需要存储一些项目，以后外部API使用者可能需要检索这些项目。 一切都存储在表foos ，当前的计划是仅使用表的主ID密钥作为外部唯一标识符。 我的直觉告诉我这是一个糟糕的设计，但是我无法有效地论证我的观点，部分原因是我无法阐明原因。

到目前为止，这是我唯一能想到的缺点：

• 如果我们要更改架构怎么办？ 我们必须重新填充所有内容以确保其ID保持不变，或者在移动过程中实现另一个唯一标识符列
• 次要（？）安全风险（我知道，通过默默无闻的安全性是不安全的，等等）

还有其他主要缺点吗？还是我只是偏执？ 也将感谢一些有关此的已发表文章的链接！

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

Answer 2

这是绝对安全的。 这些ID将与其余数据一起备份和还原，因此没有问题。 我也没有想到任何安全问题。 设计是否不好取决于品味。

IIRC eBay和PayPal API以这种方式工作，但是我无法对此进行引用。

Answer 3

因为您的第一点，我同意您的观点：

如果由于某种原因最终更改架构，则您的服务应抽象出物理更改。 维护旧密钥非常困难。