След като използва ObjectId s в RESTful API няколко пъти, най-големият недостатък наистина е, че те са много шумни по отношение на чист URL. Или ще го оставите като HEX число, или ще го преобразувате в много голямо цяло число, като и двете ще направят донякъде неприветлив URL:
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
Добавих „заглавие“ към URL адреса (както прави StackOverflow), за да ги направя малко по-приятелски:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Разбира се, "заглавието" се игнорира в софтуера, но потребителят го вижда и може мислено да игнорира лудия сегмент на ID.
Има много малко полезни неща, които могат да се научат от инфраструктурата, като ги разкрием:
- Часово клеймо
- Идент. № на машината
- Идентификатор на процеса
- Случайна нарастваща стойност
Освен потенциално събиране на машинни идентификатори (които обикновено показват броя на клиентите, създаващи ObjectId s), няма много.
ObjectId s не са произволни, така че не можете да ги използвате за сигурност. Винаги ще трябва да защитите данните. Въпреки че може да не се увеличават по очевиден начин, би било лесно да се намерят други ресурси чрез груба сила. Въпреки това, ако преди сте използвали автоматично увеличаващи се идентификатори, това не е нов проблем за вас.
Ако знаете, че не създавате много нови документи в даден момент, може да си струва да използвате един от шаблоните тук, за да създадете по-опростен идентификатор. В едно приложение, което написах, използвах техника за автоматично включване за някои от идентификаторите на документи, които бяха показани в URL адреси, а за тези, които бяха само за Ajax, използвах ObjectId с. Наистина исках някои URL адреси да бъдат лесно „набрани“. Няма форма на ObjectId се въвежда лесно от краен потребител. Това е една от силните страни на MongoDB – че можете да използвате всеки _id формат, който искате. :)
