I'm using mongoDB for the first time in a RESTful service. Previously the id column in my SQL databases was an incrementing integer so my RESTful endpoints would look something like /rest/objectType/1. Is there any reason why I shouldn't just use mongoDB's ObjectId's in the same role, or is it wiser to maintain a separate incrementing integer id column and use this for urls?
我在RESTful服务中第一次使用mongoDB。以前我的SQL数据库中的id列是一个递增的整数，所以我的RESTful端点看起来像/ rest / objectType / 1。我有什么理由不在同一个角色中使用mongoDB的ObjectId，或者维护一个单独的递增整数id列并将其用于url更明智？
2 个解决方案
#1
15
Having used ObjectIds in RESTful APIs several times, the biggest downside is really that they are very noisy in terms of having a clean URL. You'll either leave it as a HEX number, or convert it to a very large integer number, both making for a somewhat unfriendly URL:
在RESTful API中多次使用ObjectIds，最大的缺点是它们在拥有干净的URL方面非常嘈杂。您要么将其保留为十六进制数字，要么将其转换为一个非常大的整数，这两者都会产生一些不友好的URL：
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
I've added a "title" to the URL (like * does) to make them slightly more friendly:
我在URL中添加了一个“标题”（就像*一样），使它们更加友好：
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Of course, the "title" is ignored in software, but the user sees it and can mentally ignore the crazy ID segment.
当然，软件会忽略“标题”，但用户会看到它并且可以在心理上忽略疯狂的ID段。
There's very little useful that could be learned from the infrastructure by exposing them:
通过公开它们可以从基础设施中学到很少的用处：
- Timestamp
- 时间戳
- Machine ID
- 机器ID
- Process ID
- 进程ID
- Random incrementing value
- 随机递增值
Other than potentially gathering Machine IDs (which generally would indicate the number of clients creating ObjectIds), there's not much there.
除了可能收集机器ID（通常表示创建ObjectIds的客户端数量）之外，其他方面并不多。
ObjectIds aren't random, so you couldn't use them for security. You'll always need to secure the data. While they may not increment in an obvious way, it would be easy to find other resources through brute force. However, if you were using auto-incrementing IDs before, this isn't a new problem for you.
ObjectIds不是随机的，因此您无法将它们用于安全性。您始终需要保护数据。虽然它们可能不会以明显的方式增加，但通过蛮力很容易找到其他资源。但是，如果您之前使用自动递增ID，则这不是一个新问题。
If you know you aren't creating many new documents at any given time, it might be worth using one of the patterns here to create a simpler ID. In one app I wrote, I used an auto-inc technique for some of the document IDs that were shown in URLs, and for those that were Ajax-only, I used ObjectIds. I really wanted some URLs to be easily "typed". No form of an ObjectId is easily typed by an end user. That's one of the strengths of MongoDB -- that you can use any _id format you want. :)
如果您知道在任何给定时间都没有创建许多新文档，则可能需要使用其中一种模式来创建更简单的ID。在我写的一个应用程序中，我使用了一个auto-inc技术来处理URL中显示的一些文档ID，而对于那些只使用Ajax的应用程序，我使用了ObjectIds。我真的希望一些URL能够轻松“打字”。最终用户无法轻易键入任何形式的ObjectId。这是MongoDB的优势之一 - 您可以使用任何您想要的_id格式。 :)
#2
7
It's wiser to use the ObjectIds, because keeping an incrementing counter can be a bottleneck. Also, since ObjectId contains a timestamp and is monotonic, they can be helpful in optimizing queries.
使用ObjectIds更明智，因为保持递增计数器可能是一个瓶颈。此外，由于ObjectId包含时间戳并且是单调的，因此它们可以帮助优化查询。
The ObjectIds can be guessed, but since that is definitely true for incrementing IDs, I suspect you didn't rely on security through obscurity before, so that's no trouble for you.
可以猜到ObjectIds，但由于这对于递增ID肯定是正确的，我怀疑你之前没有通过默默无闻地依赖安全性，所以这对你来说没有问题。
A downside, albeit a small one, is that the creation time on your server leaks to the user, i.e. if the user is able to identify this as an ObjectId, she can reverse-engineer the creation time of the object. That's the only potential issue I see.
虽然是一个小的缺点，但是服务器上的创建时间泄露给用户，即如果用户能够将其识别为ObjectId，则她可以对对象的创建时间进行反向工程。这是我看到的唯一潜在问题。
#1
15
Having used ObjectIds in RESTful APIs several times, the biggest downside is really that they are very noisy in terms of having a clean URL. You'll either leave it as a HEX number, or convert it to a very large integer number, both making for a somewhat unfriendly URL:
在RESTful API中多次使用ObjectIds，最大的缺点是它们在拥有干净的URL方面非常嘈杂。您要么将其保留为十六进制数字，要么将其转换为一个非常大的整数，这两者都会产生一些不友好的URL：
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
I've added a "title" to the URL (like * does) to make them slightly more friendly:
我在URL中添加了一个“标题”（就像*一样），使它们更加友好：
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Of course, the "title" is ignored in software, but the user sees it and can mentally ignore the crazy ID segment.
当然，软件会忽略“标题”，但用户会看到它并且可以在心理上忽略疯狂的ID段。
There's very little useful that could be learned from the infrastructure by exposing them:
通过公开它们可以从基础设施中学到很少的用处：
- Timestamp
- 时间戳
- Machine ID
- 机器ID
- Process ID
- 进程ID
- Random incrementing value
- 随机递增值
Other than potentially gathering Machine IDs (which generally would indicate the number of clients creating ObjectIds), there's not much there.
除了可能收集机器ID（通常表示创建ObjectIds的客户端数量）之外，其他方面并不多。
ObjectIds aren't random, so you couldn't use them for security. You'll always need to secure the data. While they may not increment in an obvious way, it would be easy to find other resources through brute force. However, if you were using auto-incrementing IDs before, this isn't a new problem for you.
ObjectIds不是随机的，因此您无法将它们用于安全性。您始终需要保护数据。虽然它们可能不会以明显的方式增加，但通过蛮力很容易找到其他资源。但是，如果您之前使用自动递增ID，则这不是一个新问题。
If you know you aren't creating many new documents at any given time, it might be worth using one of the patterns here to create a simpler ID. In one app I wrote, I used an auto-inc technique for some of the document IDs that were shown in URLs, and for those that were Ajax-only, I used ObjectIds. I really wanted some URLs to be easily "typed". No form of an ObjectId is easily typed by an end user. That's one of the strengths of MongoDB -- that you can use any _id format you want. :)
如果您知道在任何给定时间都没有创建许多新文档，则可能需要使用其中一种模式来创建更简单的ID。在我写的一个应用程序中，我使用了一个auto-inc技术来处理URL中显示的一些文档ID，而对于那些只使用Ajax的应用程序，我使用了ObjectIds。我真的希望一些URL能够轻松“打字”。最终用户无法轻易键入任何形式的ObjectId。这是MongoDB的优势之一 - 您可以使用任何您想要的_id格式。 :)
#2
7
It's wiser to use the ObjectIds, because keeping an incrementing counter can be a bottleneck. Also, since ObjectId contains a timestamp and is monotonic, they can be helpful in optimizing queries.
使用ObjectIds更明智，因为保持递增计数器可能是一个瓶颈。此外，由于ObjectId包含时间戳并且是单调的，因此它们可以帮助优化查询。
The ObjectIds can be guessed, but since that is definitely true for incrementing IDs, I suspect you didn't rely on security through obscurity before, so that's no trouble for you.
可以猜到ObjectIds，但由于这对于递增ID肯定是正确的，我怀疑你之前没有通过默默无闻地依赖安全性，所以这对你来说没有问题。
A downside, albeit a small one, is that the creation time on your server leaks to the user, i.e. if the user is able to identify this as an ObjectId, she can reverse-engineer the creation time of the object. That's the only potential issue I see.
虽然是一个小的缺点，但是服务器上的创建时间泄露给用户，即如果用户能够将其识别为ObjectId，则她可以对对象的创建时间进行反向工程。这是我看到的唯一潜在问题。