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

Question

我们正在设计一个带有外部API的HTTP服务，该服务需要存储一些外部API消费者可能需要稍后检索的项目。所有内容都存储在表foos中，当前计划只是使用表的主ID键作为外部唯一标识符。我的直觉告诉我这是一个糟糕的设计，但我无法有效地论证我的情况，部分原因是因为我无法明确说明理由。

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

• 如果我们想要更改架构怎么办？我们将不得不重新填充所有内容以确保其ID保持不变，或在移动期间实施另一个唯一标识符列
• 轻微（？）安全风险（我知道，通过默默无闻的安全性等等）

还有其他主要缺点，还是我只是偏执狂？也会欣赏一些链接到已发表的文章来谈论这个！

Answer 1

我要继续说，如果你的数据库被锁定，那么除非：

• 共享API密钥意味着C.I.A.用户信息。
• 用户无需二级身份验证即可轻松调用API。

我确信你已经意识到采取针对SQL注入的措施将阻止任何人利用这些信息，但是知道一个索引范围可能意味着有人会知道在索引范围内少1或1以上是用于访问API的有形密钥。

---

例如：

如果您可以在不登录的情况下通过URL访问API，那么使用索引范围是不好的 http://mysite.com?APIkey=145
如果我知道我的密钥 145 ，那么 144 和 146 可能也可以拨打电话。

使用GUID方案是解决这个问题的方法，但是你正在制作其他sacrifices：
ID（索引）： 145
ID（GUID）： C87FC84A-EE47-47EE-842C-29E969AC5131

---

或者最后，您可以添加另一个列来保存随机哈希作为唯一的API密钥，如您所说：
ID（哈希）： da39a3ee5e6b4b0d3255bfef95601890afd80709

Answer 2

非常安全。这些ID将与其余数据一起备份和恢复，因此没有问题。也没有任何我能想到的安全问题。是否糟糕的设计是一个品味问题。

IIRC eBay和PayPal API以这种方式工作，但我不能引用它的参考。

Answer 3

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

如果最终因为任何原因更改架构，您的服务应该抽象出物理更改。维护旧密钥非常困难......