Чи слід використовувати UUID для ресурсів у своєму загальнодоступному API?

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

Я задоволений таким підходом, але мені цікаво, чому я не можу знайти API від великих програвачів SaaS / хостингу, які роблять те саме? Наприклад:

• Shopify: 9 цифр
• Твіліо: 34 рядки символів
• Twitter: 20+ цифр
• AMEE: 12 символів A-Z0-9

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

Цілком можливо, що інші перелічені вами постачальники мають власні ідентифікатори або схему хешування, щоб дозволити їм виставляти меншу кількість, одночасно використовуючи щось більше схоже на UUID. Але врешті-решт, слід поставити запитання: поки ваші URI призначені для споживання кодом (клієнтами API), а не людьми, чому це має значення?

Не надто збивайтеся з того, що зробили ці продавці. Немає гарантії, що (а) вони роблять "правильно" і (б) що їхні потреби збігаються з вашими.

Вперед і використовуйте UUID.

Я думаю, ви можете тут розглянути чотири основні варіанти:

1. використовуйте UUID як основні ключі бази даних, але це може бути обчислювально дорожче, ніж використання Long

2. створити рівень UUID для відображення Long, таким чином ви можете публікувати свої ресурси REST, але підтримувати чисту структуру бази даних, використовуючи Long PK

3. створити стовпець Альтернативний ключ у таблицях бази даних, щоб зберігати значення UUID.

4. замість використання UUID ви можете мати криптографічні ідентифікатори, що генеруються на льоту, використовуючи спеціальне насіння для кожного клієнта та оригінальний ПК. Цей підхід накладає більше накладних витрат, але може бути цікавим у деяких сценаріях. Клієнту доведеться використовувати завжди зашифровані дані, оскільки вони ніколи не матимуть доступу до насіння або алгоритму.