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来创建和更新我的笔记，这意味着客户设置/生成新笔记的ID。

我想过使用GUID / UUID，但它们很长，并且会让记住URL变得非常困难。同样从数据库的角度来看，当在大表中用作主键时，从性能的角度来看，这样的长字符串id会很麻烦。

你知道一个好的id生成策略，它可以生成短ID，当然可以避免冲突吗？

Answer 1

高度分散的系统（如git，mongodb等）使用长UUID /哈希值是有原因的，而集中式关系数据库（或svn就此而言）可以简单使用int s。没有简单的方法以分布式方式在客户端创建短ID。要么服务器处理它们，要么你必须忍受浪费的id。通常，它们包含编码的时间戳，客户端/计算机ID，散列内容等。

这就是REST服务通常使用

的原因

POST /notes

用于非幂等保存，然后在响应中使用Location:标头的输出：

Location: /notes/42

REST Web服务的客户端ID生成策略

1 个答案: