客戶端ID生成策略

Question

比方說，我想建立一個REST服務做筆記，看起來是這樣的：

GET /notes/  // gives me all notes 
GET /notes/{id} // gives the note identified by {id} 
DELETE /notes/{id} // delete note 

PUT /notes/{id} // creates a new note if there is no note identified by {id} 
        // otherwise the existing note is updated 

因爲我想我使用PUT來indempotent我的服務創建並更新我的筆記 這意味着新筆記的ID由客戶端設置/生成。

我想過使用GUID/UUID，但它們很長，並且會使URL記住相當困難。同樣從數據庫的角度來看，當用作大表中的主鍵時，從性能的角度來看，這樣的長字符串ID可能是麻煩的。

你知道一個好的身份證生成策略嗎，它會生成短ID並且當然避免碰撞？

Answer 1

還有一個原因是高度分散的系統（如git，mongodb等）使用長的UUID /哈希而集中的關係型數據庫（或svn爲此事）可以簡單地使用int秒。在客戶端以分佈式方式創建短ID不是一種簡單的方法。服務器可以處理它們，或者你必須忍受浪費的ID。通常，它們含有編碼時間戳，客戶端/計算機ID，散列內容等

這就是爲什麼REST服務通常使用

POST /notes 

非冪等保存，然後使用Location:頭的輸出響應：

Location: /notes/42