14

我第一次在 RESTful 服务中使用 mongoDB。以前我的 SQL 数据库中的 id 列是一个递增的整数，所以我的 RESTful 端点看起来像/rest/objectType/1. 有什么理由我不应该只在同一角色中使用 mongoDB 的 ObjectId，或者维护一个单独的递增整数 id 列并将其用于 url 是否更明智？

4

2 回答 2

16

在 RESTful API 中多次使用ObjectIds 后，最大的缺点是它们在拥有干净的 URL 方面非常嘈杂。您要么将其保留为 HEX 数字，要么将其转换为非常大的整数，这两者都会导致 URL 有点不友好：

/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759

我在 URL 中添加了一个“标题”（就像 StackOverflow 一样），以使它们更加友好：

    /rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName

当然，“标题”在软件中被忽略了，但用户看到它，可以在精神上忽略疯狂的 ID 段。

通过暴露它们可以从基础设施中学到很少有用的东西：

  1. 时间戳
  2. 机器编号
  3. 进程 ID
  4. 随机递增值

除了可能收集机器 ID（这通常表示创建ObjectIds 的客户端数量）之外，那里没有太多东西。

ObjectIds 不是随机的，因此您不能将它们用于安全性。您将始终需要保护数据。虽然它们可能不会以明显的方式增加，但通过蛮力很容易找到其他资源。但是，如果您之前使用过自动递增的 ID，这对您来说并不是一个新问题。

如果您知道在任何给定时间都不会创建许多新文档，那么使用此处的一种模式来创建更简单的 ID 可能是值得的。在我编写的一个应用程序中，我对 URL 中显示的一些文档 ID 使用了 auto-inc 技术，而对于仅 Ajax 的那些，我使用了ObjectIds. 我真的希望一些 URL 可以轻松“输入”。ObjectId最终用户无法轻松键入任何形式的 an 。这是 MongoDB 的优势之一——您可以使用任何_id您想要的格式。:)

于 2013-09-26T14:39:46.777 回答
8

使用 s 更明智ObjectId，因为保持递增计数器可能是一个瓶颈。此外，由于ObjectId包含时间戳并且是单调的，它们有助于优化查询。

可以猜到，但由于这ObjectIds对于增加 ID 绝对是正确的，我怀疑您之前没有通过默默无闻来依赖安全性，所以这对您来说没有问题。

一个缺点（尽管很小）是服务器上的创建时间会泄露给用户，即如果用户能够将其识别为ObjectId，她可以对对象的创建时间进行逆向工程。这是我看到的唯一潜在问题。

于 2013-09-26T14:20:22.013 回答