是否有任何理由为什么我应该/不应该在我的RESTful网址中使用ObjectId

Question

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

Answer 1

多次在RESTful API中使用ObjectId，最大的缺点是它们在拥有干净的URL方面非常嘈杂。您可以将其保留为十六进制数字，也可以将其转换为一个非常大的整数，这两者都会产生一些不友好的URL：

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

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

    /rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName

当然，软件会忽略“标题”，但用户会看到它并且可以在心理上忽略疯狂的ID段。

通过公开它们可以从基础设施中学到很多有用的东西：

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

除了可能收集机器ID（通常表示创建ObjectId s的客户端数量）之外，其他地方并不多。

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

如果您知道在任何给定时间都没有创建许多新文档，则可能需要使用其中一种模式here来创建更简单的ID。在我写的一个应用程序中，我对URL中显示的一些文档ID使用了auto-inc技术，对于那些仅使用Ajax的应用程序，我使用了ObjectId s。我真的希望一些URL能够轻松“打字”。最终用户无法轻易键入任何形式的ObjectId。这是MongoDB的优势之一 - 您可以使用任何您想要的_id格式。 ：）

Answer 2

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

可以猜到ObjectIds，但由于这对于递增ID肯定是正确的，我怀疑你之前没有依赖安全性，所以这对你来说没有问题。

虽然是一个小的缺点，但是服务器上的创建时间泄露给用户，即如果用户能够将其识别为ObjectId，则她可以对创建时间进行反向工程。物体。这是我看到的唯一潜在问题。