Потрібно, щоб ідентифікатори бекенда були відкритими чи не були в API REST?


14

На основі того, що каже цей хлопець: 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.

Відповіді:


7

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

Які ще засоби ви повинні ідентифікувати ваші особи, коли вони повертаються через запит? Це абсолютно законно і безпечніше, ніж SSN або подібні ідентифікатори. Це те, про що говорить Тодд - зробити технологію ідентифікації та сутність нейтральною, і він має рацію.

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

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


Ви маєте рацію щодо викриття ідентифікатора. Щодо ефективності, я все ще не бачу, як я можу використовувати обидва ідентифікатори. Якщо клієнт зробить запит з uuid, то я зроблю запит на пошук в полі uuid і отримаю результат. Я не можу знати об'єктиву, поки не отримаю сутність. Тому я думаю, що немає сенсу використовувати обидва.
anat0lius

1
Це може мати сенс для підтримки спадщини. Скажімо, на старий автономерний ідентифікатор як і раніше посилаються на застарілі дані чи / та системи. В іншому випадку, цілком можливо працювати просто з UUID
Laiv

1
У відповідь на ваше запитання " Якими ще засобами ви повинні ідентифікувати своїх організацій, коли вони повертаються через запит? ", Ідентифікатори проксі-сеансів за сеанс. " Найкращий захист - це уникати відкриття прямих посилань на об'єкти користувачам за допомогою індексу, непрямої довідкової карти чи іншого непрямого методу, який легко перевірити "
Пітер Тейлор

5

Ні, що стосується бази даних, нічого про внутрішню структуру не піддається зовнішньому API. Ідентифікатори не мають інтелекту. Вони навіть не унікальні в реальному світі. ID: 47 є скрізь. Є суб'єкти, до яких ви маєте доступ і, можливо, маніпулюєте даними, але чи зберігає ця база даних все в одній таблиці чи десяти, використовує додатковий ідентифікатор як ПК та стосується ФК, ви ніколи не дізнаєтесь.

Якщо ви можете GetUserAccountByID (12345), просто просите когось спробувати GetUserAccountByID (12346). Навіть якщо це не спрацює через інші заходи безпеки, навіть не намагайтесь і не намагайтеся зламати компанію, запитуючи інформацію на рахунок: 12346. Якщо ви не зателефонуєте в DBA і не будете готові чекати 2 тижні на відповідь;)

Тому створіть GUID, однак ви вважаєте за потрібне чи будь-який інший природний ключ, наприклад номер телефону чи електронну адресу. Покладіть унікальне обмеження на поле в таблиці, щоб уникнути деякої незрозумілої спроби копіювання та вставки в якійсь спробі злиття даних.

Це не зайве. Два поля служать різним цілям.


0

Щодо ідентифікатора ефективності та UUID, якщо у вас є кілька приєднань із залученням декількох таблиць, кожна з яких має мільйонні записи, це не призведе до великої різниці. Використання UUID зробить ваш додаток набагато складнішим, коли ви не перевірите / застосуєте прямо на стороні сервера.

  • ПОТРІБНО [...] / 1
  • ДОВІЙТЕ [...] / 2

При використанні ідентифікатора це дуже просто, якщо ви використовуєте UUID замість цього, це один варіант менш для скрепера.

Ідентифікатор може розглядатися як щось внутрішнє в екземплярі бази даних вашої програми. У цьому реченні є три важливі слова:

  • Застосування: оскільки це ваша модель, цілком імовірно, що ваші таблиці використовуються тільки цим додатком
  • База даних: Якщо декілька застосувань використовували її для однієї бази даних, ви все добре
  • Екземпляр (бази даних): якщо у вас розподілена система, ідентифікатор буде конфліктувати між собою, і вони будуть безглуздими для будь-якої іншої системи / програми, яка не використовує екземпляр вашої бази даних. UUID - це рішення для конкретного випадку.

Щодо особистої переваги: ​​я вважаю за краще простий ідентифікатор та унікальний ідентифікатор компанії (пошта, логін, ...). Тож якщо мені доведеться обмінюватися даними, я використовуватиму ідентифікатор бізнесу, оскільки цільова система може не обробляти UUID, але він дуже ймовірно (ніколи не кажіть ніколи ...) добре обробляти унікальний бізнес-ключ.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.