您在示例中描述的内容称为RESTful服务URL，非常适合设计API或Web App。
小心你的URL深度，因为最好的做法是将其限制在resource/identifier/resource，任何比这更深的建议审查你的设计。
使用mongodb自动生成的ObjectId是一个很好的标识符候选者，它可以在数据库中唯一地标识你的资源，这样你就可以在url中使用它们。只是不要在url中暴露任何敏感信息，并确保你有身份验证和授权来保护你的路由，特别是那些改变数据的路由。

在url中使用objectId可能会有两个问题：
1.将objectId公开并不是一个好的做法。我个人不认为这会带来安全风险，但它可能看起来不专业。
1.还有一个实际的部分，objectId通常很长，对一个人来说没有意义，所以它看起来并不漂亮，比如你使用了产品的名称。
老实说，我相信这并不重要，除非你想在某个地方分享链接，格式**../recipe/：recipeName/：objectName**可能会更好。

我会投反对票，这（可能）不是一个好主意。
现在，确实，MongoDB ObjectId是一个非常好的数据，12字节，具有非常广泛的域。但我看到2个缺点：
1.时间戳嵌入在ObjectId中，因此理论上您可以泄漏有关标识符的信息：

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

字符串

1. （这一个更哲学一点）。提供给消费者的API和密钥应该只暴露业务或本地上下文数据，而不是DB内部数据类型。是的，_id中使用的ObjectId比Oracle和postgres中的ROWID和ctid更持久。它是一个真实的独立数据类型，就像UUID一样，但它仍然与MongoDB“环境”相关。
   如果你想在一个URL中使用它，要非常小心地控制它的创建以及它如何处理URL上的入站。记住，像UUID（以及常规字符串和数字）这样的东西在MongoDB驱动程序中不会自动生成，但是_id具有自动生成的特殊功能。
   另外，相关的，考虑转储和重新加载数据的影响。如果你没有完全控制_id（假设这是你正在使用的ObjectId），那么你最终可能会得到 newObjectId，它与过去生成的URL不匹配。