是否有任何理由为什么我应该/不应该在我的RESTful url中使用ObjectId [英] Are there any reasons why I should/shouldn't use ObjectId's in my RESTful url's

问题描述

我在第一次使用mongoDB进行RESTful服务。以前，我的SQL数据库中的id列是一个递增的整数，所以我的RESTful端点看起来像 / rest / objectType / 1 。有没有什么理由我不应该只是使用mongoDB的ObjectId在同一个角色，还是更明智地维护一个单独的递增整数id列，并使用这个url？

解决方案

在RESTful API中多次使用了 ObjectId ，最大的缺点是他们非常嘈杂，网址你可以将它作为一个十六进制数字，或将其转换成一个非常大的整数，这两个都是一个有点不友好的URL：

  / rest / resource / 52435dbecb970072ec3a780f 
 / rest / resource / 25459211534898951476729247759 
  

ve添加了一个标题到URL（像StackOverflow），使它们稍微更友好：

  / rest / resource / 52435dbecb970072ec3a780f / FriendlyResourceName 
  

当然，标题在软件中被忽略，但用户看到它，可以精神上忽略这个疯狂的ID段。

通过暴露他们，可以从基础架构中学到一些有用的东西：

1. 时间戳


2. 机器ID


3. 进程ID


4. 随机递增值

除了潜在收集机器ID（通常会指示创建 ObjectId s），没有太多。

ObjectId 不是随机的，所以你可以不要将它们用于安全。您将始终需要保护数据。虽然它们可能不会以明显的方式增加，但是通过暴力来找到其他资源也很容易。但是，如果您之前使用自动递增ID，这对您来说不是一个新问题。

如果您知道您没有创建任何新的文档给定时间，可能值得使用此处中的其中一种模式创建一个更简单的ID。在我写的一个应用程序中，我使用了一些auto-inc技术来显示URL中的一些文档ID，对于那些只有Ajax的文档，我使用了 ObjectId s。我真的想要一些URL很容易打字。最终用户很容易键入 ObjectId 的形式。这是MongoDB的优势之一 - 您可以使用任何您想要的 _id 格式。 ：）

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?

解决方案

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

I've added a "title" to the URL (like StackOverflow does) to make them slightly more friendly:

    /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.

There's very little useful that could be learned from the infrastructure by exposing them:

1. Timestamp
2. Machine ID
3. Process ID
4. Random incrementing value

Other than potentially gathering Machine IDs (which generally would indicate the number of clients creating ObjectIds), there's not much there.

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.

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屋！