有什么原因我应该/不应该在我的 RESTful url 中使用 ObjectId [英] Are there any reasons why I should/shouldn't use ObjectId's in my RESTful url's
问题描述
我第一次在 RESTful 服务中使用 mongoDB.以前，我的 SQL 数据库中的 id 列是一个递增的整数，因此我的 RESTful 端点看起来类似于 /rest/objectType/1.有什么理由我不应该只在同一角色中使用 mongoDB 的 ObjectId，或者维护一个单独的递增整数 id 列并将其用于 url 是否更明智?
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 API 中多次使用 ObjectIds，最大的缺点是它们在拥有干净的网址.您要么将其保留为十六进制数，要么将其转换为一个非常大的整数，这两者都会导致 URL 有点不友好:
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:
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
我在 URL 中添加了一个标题"(就像 StackOverflow 所做的那样)以使它们更友好一些:
I've added a "title" to the URL (like StackOverflow does) to make them slightly more friendly:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
当然，title"在软件中是被忽略的，但是用户看到了，心理上可以忽略这个疯狂的ID段.
Of course, the "title" is ignored in software, but the user sees it and can mentally ignore the crazy ID segment.
通过公开基础设施可以从基础设施中学到很少有用的东西:
There's very little useful that could be learned from the infrastructure by exposing them:
- 时间戳
- 机器 ID
- 进程 ID
- 随机递增值
除了可能收集机器 ID(通常表示创建 ObjectId 的客户端数量)之外，没有太多.
Other than potentially gathering Machine IDs (which generally would indicate the number of clients creating ObjectIds), there's not much there.
ObjectId 不是随机的，因此您不能使用它们来确保安全.您将始终需要保护数据.虽然它们可能不会以明显的方式增加，但通过蛮力很容易找到其他资源.但是，如果您之前使用过自动递增 ID，那么这对您来说并不是一个新问题.
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.
如果您知道在任何给定时间都不会创建很多新文档，则可能值得使用其中一种模式 此处 创建更简单的 ID.在我编写的一个应用程序中，我对显示在 URL 中的一些文档 ID 使用了一种 auto-inc 技术，对于那些仅支持 Ajax 的文档，我使用了 ObjectIds.我真的希望可以轻松键入"一些 URL.最终用户无法轻松输入任何形式的 ObjectId.这是 MongoDB 的优势之一——您可以使用任何您想要的 _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. :)
这篇关于有什么原因我应该/不应该在我的 RESTful url 中使用 ObjectId的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
