使用數據庫表的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

因為您的第一點，我同意您的觀點：

如果由於某種原因最終更改架構，則您的服務應抽象出物理更改。 維護舊密鑰非常困難。