Существуют ли какие-либо причины, по которым я должен/не должен использовать ObjectId в моем URL-адресе RESTful

Я впервые пользуюсь mongoDB в службе RESTful. Раньше столбец id в моих SQL-базах данных был инкрементирующим целым числом, поэтому мои конечные точки RESTful выглядели бы как /rest/objectType/1. Есть ли какая-то причина, по которой я не должен просто использовать mongoDB ObjectId в той же роли, или разумнее поддерживать отдельный столбец с добавочным целым числом и использовать это для URL?

Ответы

Ответ 1

Несколько раз использовав ObjectId в API RESTful, самый большой недостаток - действительно, что они очень шумные с точки зрения наличия чистого URL-адреса. Вы либо оставите его как HEX-номер, либо конвертируете его в очень большое целое число, как для недружественного URL-адреса:

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

Я добавил URL-адрес в URL (например, StackOverflow), чтобы сделать их несколько более дружественными:

    /rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName

Конечно, "title" игнорируется в программном обеспечении, но пользователь видит его и мысленно игнорирует безумный сегмент ID.

Очень мало полезного, что можно было бы узнать из инфраструктуры, разоблачив их:

  • Отметка
  • Идентификатор машины
  • Идентификатор процесса
  • Случайное значение приращения

Помимо потенциального сбора идентификаторов машины (которые обычно указывают количество клиентов, создающих ObjectId s), там не так много.

ObjectId не являются случайными, поэтому вы не можете использовать их для обеспечения безопасности. Вам всегда нужно защищать данные. Хотя они могут не увеличиваться очевидным образом, было бы легко найти другие ресурсы с помощью грубой силы. Однако, если вы использовали автоинкрементные идентификаторы раньше, это не новая проблема для вас.

Если вы знаете, что не создаете много новых документов в любой момент времени, возможно, стоит использовать один из шаблонов здесь, чтобы создать более простой идентификатор. В одном приложении, которое я написал, я использовал метод auto-inc для некоторых идентификаторов документов, которые были показаны в URL-адресах, а для тех, которые были только Ajax, я использовал ObjectId s. Я действительно хотел, чтобы некоторые URL-адреса были легко "напечатаны". Конечный пользователь легко набирает форму ObjectId. Это одна из сильных сторон MongoDB - вы можете использовать любой формат _id, который вы хотите.:)

Ответ 2

Разумно использовать ObjectId s, потому что сохранение счетчика приращений может быть узким местом. Кроме того, поскольку ObjectId содержит метку времени и является монотонным, они могут быть полезны при оптимизации запросов.

ObjectIds можно угадать, но поскольку это определенно верно для увеличения идентификаторов, я подозреваю, что раньше вы не полагались на безопасность через неясность, так что вам не было неприятностей.

Недостаток, хотя и небольшой, заключается в том, что время создания на вашем сервере утечки для пользователя, то есть если пользователь может идентифицировать это как ObjectId, она может перепрограммировать время создания объекта, Это единственная потенциальная проблема, которую я вижу.