在Web服務URL中使用加密的數據庫ID而不是UUID是好主意嗎？

Question

美好的一天，我實施了一項REST服務。在資源終點的URL中，使用數據庫表的主鍵ID。例如http://host/myapp/items/item/4。我知道在URL中使用數據庫ID是一種不好的做法，我應該使用UUID代替。另一方面，我知道如果數據庫中有很多記錄，那麼在索引中使用UUID是一個性能問題，因爲它們不是順序的（1,2,3，...）。所以我有一個想法來加密數據庫ID。這是怎麼可能的工作：

1) Client POSTs an item to `http://host/myapp/items`. 
2) The back-end creates a new item in the database. 
3) Autoincremented ID '4' is generated by the database. 
4) The back-end encrypts the ID '4' to 'fa4ce3178a045b2a' using a cipher key and returns encrypted ID of a created resource. 

然後：

5) Client sends a request to GET `http://myapp/items/item/fa4ce3178a045b2a`. 
6) The back-end decrypts 'fa4ce3178a045b2a' to '4' using an cipher key. 
7) The back-end fetches item with primary key '4' and sends it to the client. 

什麼是這樣的解決方案的利弊？加密/解密是否會足夠快以至於使用UUID並不會更糟？我應該使用什麼加密算法，以便速度快並且不佔用太多資源？能否有人提供更有經驗的建議或推薦更好的解決方案？先謝謝你。 Vojtech

Answer 1

我不認爲我們可以預測哪個更快：在數據庫中使用UUID或者加密和解密IDS。它可以取決於數據庫的類型，數據庫所在的計算機以及實際的請求。

例如，當您想要列出許多資源並且想要添加指向詳細視圖的鏈接時，必須加密每個資源的編號才能組成響應。現在通過一個很長的列表，這可能比稍慢的選擇需要更長的時間，所以我不會使用它。

我不認爲這是一個真正的瓶頸。我認爲HTTP通信是瓶頸，所以爲了讓事情更快，您應該考慮正確設置HTTP緩存。順便說一句。如果你真的想隱藏你的ID，你應該測量速度，而不是讓我們猜測它們。

Answer 2

是的，id有時是不受歡迎的。客戶端可以預測並生成鏈接。可以檢查你的數據庫有多大等，但有時候並不重要，然後id完全可以。

最快的密碼是對稱的。有關詳細信息，你必須找到/做一些基準。示例在這裏：http://stateless.geek.nz/2004/10/13/scp-performance/

但我不認爲任何人都可以告訴你，如果加密的過程將比使用uuid更快。它取決於您的數據庫大小，您使用的索引，緩存，硬件等。執行性能測試。如果速度對你至關重要，你可以考慮在內存中存儲翻譯地圖/表格（uuid - > id）