Будь ласка, припинить виставляти автоінкрементні ідентифікатори назовні. В урлах, в API, будь-де. З ними погано все:
• Ти видаєш назовні дані про те, скільки в тебе цих сутностей. Можливо тобі взагалі це фіолетово, особливо під час розробки, але бізнес-сторона не скаже тобі дякую потім за те, що всі конкуренти в курсі, як добре йде твій бізнес.
• Ти даєш дуже простий інтерфейс для парсингу всіх даних від тебе: звичайним циклом можна забрати абсолютно все.
• Вони виглядають однаково. Коли в тебе багато сутностей і багато айдішників, в якийсь момент ти в них заплутаєшся. :)
• Жодної семантики в них нема. Коли починається якийсь дебаг з 10-20 різними типами сутностей і айдішників — голова закипає.
• Ти їх видаси у своєму JSON'і як числа і тоді шансів щось змінити в тебе буде обмаль. Трохи нижче про це напишу.
То що ж робити?
• Найкраще — то коли ти можеш виставити назовні щось семантичне, slug. Перетворити у латинку нижнім регістром заголовок поста, назву фільтра чи його значення — це все нескладно, і якщо кількість сутностей дозволяє, нормально працює унікальним ідентифікатором.
• Якщо назва не дозволяє унікальності, можна додати до неї айдішник. Так, першу проблему ти не закриваєш, але всі інші закриваєш.
• Нема якоїсь конкретної назви або треба щось коротке? Візьми hashids, вони закодують твої циферки і якусь сіль у не дуже довгий рядок, і імплементація настільки проста, що є фактично для всього. На додаток, якщо з імплементації вирізати можливість мати списки, то результат ще й трошки коротшим стає IIRC. Плюс можна дати власну абетку, щоб не було схожих літер і простіше було людям прочитати це (для нас цей кейс важливий був, коли люди дзвонили у кол-центр з номерами замовлень).
• Комбінація назви та hashids, щоб таки не палити айдішник назовні.
• Проблему з однаковим виглядом можна, для найважливіших кейсів, вирішити префіксом, або якимось форматом. В Амазона формат номера замовлення
\d{3}-\d+-\d+ (вчіть регекспи), в Касти K[\d\w]+, різне можна зробити. Це, до речі, дуже корисно для кількох найважливіших сутностей, коли вони регулярно вилазять в різних місцях, особливо у спілкуванні нетехнічних людей.• Якщо фантазії взагалі не вистачає, візьми UUID4. Так, він довгий, це неможливо сказати вголос іншій людині, ти їх не будеш розрізняти між собою, але ти хоча б закриєш перші дві проблеми та не будеш видавати зайвих даних на волю.
Про числа. Всі фронтендери поділяються на два типи: тих, кому пофіг на типізацію (жс), і тих, хто робить життя людей нестерпним (всі інші). Уявімо, що ви писали першу реалізацію якомога швидше і всюди повидавали айдішники. А потім захотіли з них переїхати на що завгодно: на префікси, на base64, на UUID. Але не можете, бо всі клієнтські апки ваші айдішники розбирають як число і строку туди не підкласти ніколи. Для міграції залишається дві опції — від'ємні числа і якась хитра арифметика (додайте трильйон і сподівайтеся що ваші клієнти розумініші за int32 🤣).
Тому ніколи — чуєте, ніколи — не віддавайте ідентифікатори як число. Зробіть
{"id": str(id)}, тоді у вас будуть шанси у майбутньому. Тим паче якщо ви віддасте їх як число, якийсь дуже розумний™ фронтендер десь помітить закономірність і щось оптимізує. Чи то швиденько пагінацію свою намутить (до речі, використовуйте курсори), чи ще якоюсь арифметикою займеться (деякі події зі свого життя я навіть не хочу розповідати 😅).Найголовніше. Який би ти айдішник не згенерував, обов'язково запиши його в базу. Не треба оцих муток "я в апі розберу hashid назад у цифру і зроблю запит по ній", це, по-перше, довше, а, по-друге, ти задовбешся шукати руками в базі, логах та обмінах повідомленнями. Просто консистентно ідентифікуй всюди цю сутність її айдішником. Може і FK на цей айдішник варто робити, тут вже я не певен. :)