Должны ли внутренние идентификаторы быть открытыми или нет в REST API?

На основании того, что говорит этот парень: http://toddfredrich.com/ids-in-rest-api.html

Предположим, он прав в использовании UUID для идентификации ресурсов API. Затем я сталкиваюсь с проблемами, пытаясь реализовать это таким образом:

class FooEntity {

    final String id = null;  //auto-generated by my backend (mongodb), not shared
    final UUID uid = UUID.randomUUID();  //the resource id
}

(Между клиентом и сервером отправляются и принимаются DTO, а не объекты базы данных.)

Проблема в том, что idэто бесполезно, так как я больше им не пользуюсь. Клиент делает запросы с uidтем, почему я пытаюсь обрабатывать 2 идентификатора? Тогда мы вернемся к той же проблеме начала. Если я устанавливаю UUID в качестве первичного ключа ( _id), то я предоставляю публичный идентификатор бэкенда.

Кроме того, есть тема эффективности. Я читал, что индексирование по ObjectId намного более эффективно, чем UUID.

Я выставляю бэкэнд-идентификатор на публику

Какими еще способами вы можете идентифицировать свои объекты, когда они возвращаются по запросу? Это совершенно законно и безопаснее, чем SSN или подобные идентификаторы. Это то, о чем говорит Тодд - делая технологию идентификации и сущность нейтральной, и он прав.

Тема эффективности

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

Нет, что касается базы данных, то ничего о внутренней структуре не предоставляется внешнему API. У ID нет интеллекта. Они даже не уникальны в реальном мире. ID: 47 везде. Существуют объекты, к которым у вас есть доступ и, возможно, они могут манипулировать данными, но независимо от того, хранит ли эта база данных все в одной таблице или десяти, использует инкрементный идентификатор в качестве PK и относится к FK, вы никогда не узнаете.

Если вы можете, GetUserAccountByID (12345) просто просит кого-то попробовать GetUserAccountByID (12346). Даже если это не сработает из-за других мер безопасности, даже не пытайтесь и не пытайтесь взломать компанию, запрашивая информацию в учетной записи: 12346. Если вы не позвоните администратору и не будете ждать 2 недели réponse;)

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

Это не избыточно. Эти два поля служат разным целям.

Что касается эффективности ID против UUID, если у вас есть несколько соединений, включающих несколько таблиц, каждая из которых имеет миллионы записей, это не будет иметь большого значения. Использование UUID значительно усложнит удаление вашего приложения, если вы не проверяете / не применяете его прямо на стороне сервера .:

• ПОЛУЧИТЬ [...] / 1
• ПОЛУЧИТЬ [...] / 2

Это очень просто при использовании ID, если вместо этого вы используете UUID, это на одну опцию меньше.

ID можно рассматривать как нечто внутреннее для экземпляра базы данных вашего приложения. В этом предложении есть три важных слова:

• Приложение: поскольку это ваша модель, вероятно, ваши таблицы используются только этим приложением
• База данных: если несколько приложений использовали его в одной базе данных, все в порядке
• Экземпляр (базы данных): если у вас распределенная система, id будет конфликтовать друг с другом, и они будут бессмысленными для любой другой системы / приложения, которые не используют экземпляр вашей базы данных. UUID является решением для этого конкретного случая.

По личным предпочтениям: я предпочитаю иметь простой идентификатор и уникальный бизнес-идентификатор (почта, логин, ...). Поэтому, если мне придется обмениваться данными, я буду использовать бизнес-идентификатор, потому что целевая система может не обрабатывать UUID, но он, скорее всего (никогда не скажет никогда ...), прекрасно обрабатывает уникальный бизнес-ключ.