6

假设我想构建一个 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 并且当然可以避免冲突吗？

4

1 回答 1

9

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

这就是为什么 REST 服务通常使用

POST /notes

对于非幂等保存，然后使用Location:header 的输出作为响应：

Location: /notes/42
于 2012-04-04T18:48:25.000 回答