我應該在公共API中使用UUID作爲資源嗎？

Question

我正在構建一個SaaS應用程序，並希望公開與當前數據存儲實現（Postgres自動增量ID）無關的資源的ID。這些堆棧溢出帖子（onetwo）表明創建本地唯一ID很難，我不如使用UUID，這些UUID當然可以在幾乎任何語言中輕鬆安全地生成。

我對這種方法感到滿意，但我想知道爲什麼我無法從大型SaaS /託管玩家那裏找到任何類似的API？例如：

• Shopify：9 digit numbers
• Twilio：34 character strings
• 的Twitter：20+ digit numbers
• AMEE：12 character A-Z0-9

所以基本上沒人似乎使用的UUID。有沒有這個原因 - 這裏沒有發明，更聰明的內部ID算法或其他東西？在我的情況下，在沒有任何內部算法的情況下，使用UUID最合適嗎？

Answer 1

您列出的其他供應商有可能擁有自己的ID或哈希方案，以允許他們在內部使用更類似於UUID的內容時公開更小的數字。但最後，必須提出這樣的問題：只要你的URI是被代碼（API客戶端）而不是人類消費的，爲什麼它很重要呢？

不要太被那些供應商所做的事嚇到了。 （a）他們正在做「正確的」事情，（b）他們的需求和你的需求是一樣的。

繼續並使用UUID。

Answer 2

我想你可能會認爲這裏的四個主要選項：

1. 使用UUID作爲數據庫主鍵，但它可能是更computationally expensive than using Long

2. 創建UUID龍映射層，通過這種方式，您可以發佈您的REST資源，但使用Long PK維護一個乾淨的數據庫結構。爲了保存de UUID值，在您的數據庫表中創建一個Alternate Key列。

3. 代替使用UUID，您可以使用每個客戶和原始PK的自定義種子實時生成加密ID。這種方法會產生更多的執行開銷，但在某些情況下會很有趣。客戶必須始終使用加密的數據，因爲他們永遠無法訪問種子或算法。