在 url 中使用 Mongodb ObjectId 被认为是不好的做法？

Question

我正在使用 MERN 堆栈开发一个食谱共享 Web 应用程序，我计划使用这种 url 来显示食谱信息

../recipe/:recipeName/:id

我想知道在 url 中使用 Mongodb 自动生成的 id 是否是一个不好的做法，或者我是否应该生成一个单独的公共 id。该项目是针对我的作品集的，我希望避免各种不良做法，以免吓跑招聘人员。

提前致谢！

Answer 1

您在示例中描述的内容称为“RESTful 服务 URL”，非常适合设计 API 或 Web 应用程序。 请小心您的

URL 深度

，因为最佳实践是将其限制为 resource/identifier/resource，任何更深的深度都建议对您的设计进行审查。

使用 mongodb 自动生成的

ObjectId

是一个很好的标识符候选者，可以唯一地标识数据库中的资源，以便您可以在 url 中使用它们。只是不要在 url 中暴露任何敏感信息，并确保您拥有身份验证和授权来保护您的路由，尤其是那些会改变数据的路由。

Answer 2

公开 objectId 并不是一个好习惯。我个人认为这不存在安全风险，但它可能看起来不专业。

1. 还有一个实际的部分，objectId 通常很长，对人来说没有意义，所以它看起来不太漂亮，就像你使用产品名称一样。
老实说，我相信这并不重要，除非您想在某个地方共享链接，其中格式

../recipe/:recipeName/:objectName

可能会更好。

Answer 3

现在，确实，MongoDB

ObjectId

是一个完美的数据片段，12 个字节，具有非常广泛的域。但我看到两个缺点：

时间戳嵌入在

ObjectId
1. 中，因此理论上你可以泄露有关标识符的信息：

> q = new ObjectId("656cb6485731880768c46e34");
ObjectId("656cb6485731880768c46e34")
> q.getTimestamp();
ISODate("2023-12-03T17:09:28.000Z")

（这个有点哲学）。提供给消费者的 API 和密钥应该只公开业务或本地上下文数据，而不是数据库内部数据类型。是的，

ObjectId
2. 中使用的

   _id

   比oracle和postgres中的

   ROWID

   和

   ctid

   更持久。例如，它是一个真正独立的数据类型，就像 UUID 一样。但它仍然与 MongoDB “环境”相关。
如果您确实希望在 URL 中使用它，请非常小心地控制它的创建以及它如何处理 URL 上的入站。请记住，诸如 UUID（以及常规字符串和数字）之类的内容不会在 MongoDB 驱动程序中自动生成，但

_id

具有自动生成的特殊功能。

此外，请考虑转储和重新加载数据的影响。如果您无法完全控制

_id

（假设这是您正在使用的

ObjectId

），那么最终可能会得到与过去生成的 URL 不匹配的

new

ObjectId。