在前端使用丑陋的mongodb _ids

Question

一个有点主观的问题，但我有一些担心在客户端使用mongodb _ids。我最好使用类似s52ruf6wst或xR2ru286zjI的东西来获取RESTful资源并处理小型项目集合。

1）我开始依赖后端数据库的专有实现（_id字段名称和实现）。如果我坚持使用这个_ids，那么以后更换后端数据库就更难了。

2）我有很多丑陋的URL包含mongo _ids（即使是REST端点 - 我不喜欢它）

3）对于黑客和“好奇的用户”来说，很明显使用了哪个后端数据库。

正如我所看到的，大多数Web应用程序都使用他们自己的惯例来讨论id，uid，uuids应该是什么样子，我会告诉我它看起来更专业（比使用db供应商的staightforward丑陋实现）。

所以问题是什么时候使用标准的mongo _ids并在后端和前端使用它们？那么可以做些什么来改善这种情况？

Answer 1

  

什么时候使用标准的mongo _ids

始终。除非你根本不喜欢它。但是您的个人偏好与安全性无关。 Mongo的对象id 不是本质上不如任何其他标识符类型（整数，UUID等）安全

ObjectID被设计为在整个群集中是唯一的，这非常重要，因为mongodb是一个分布式数据库。它也有一个很好的属性：值随着时间单调增加。此属性可能对您有用，也可能没用。

Answer 2

  

1）我开始依赖后端数据库的专有实现（_id字段名称和实现）。如果我坚持使用这个_ids，那么以后更换后端数据库就更难了。

这就是抽象层，框架和ODM（ORM）的用武之地。它们提供了一个标准化的层（即Doctrine 2）来查询不同类型的数据库。作为示例，id将_id和ID以及id转换为许多ORM，具体取决于您使用的数据库。

如前所述，ObjectId没有固有的安全缺陷，对于其他用户来说甚至没有那么有用，因为即使ObjectId有时间部分这一部分也不容易用于决定下一个对象是什么（与自动递增ID不同）。可靠地执行此操作的唯一方法是直到现在测试所有时间以及所有pid编号以检测是否存在隐藏对象。因此，抓取ObjectId网址实际上并不是一件容易的事情，事实上，由于这个原因，它并不是非常友好的SEO。但是，是的，他们可以知道你正在使用什么数据库。

话虽如此，是的，他们是丑陋的，但正如@Sergio所说，他们是那么漫长而丑陋，是独一无二的。制作自己的东西同样糟糕。我想你可以通过base64编码ObjectId的十六进制表示来缩小它。

但我不确定你是否真的需要它。