Должен ли я использовать UUID для ресурсов в моем публичном API?

Question

Я создаю приложение SaaS и хочу предоставить идентификаторы для ресурсов, которые не связаны с моей текущей реализацией хранения данных (идентификаторы автоматического увеличения Postgres).Эти сообщения о переполнении стека ( one two ) предполагают, что создание локально уникальных идентификаторов сложно, и что я мог бы также использовать UUID, которые, конечно, легко и безопасно генерируются практически на любом языке..

Я доволен этим подходом, но мне интересно, почему я не могу найти API от крупных SaaS / хост-плееров, которые делают то же самое?Например:

• Shopify: 9-значный номер
• Twilio: 34 строки символов
• Twitter: 20 + цифр
• AMEE: 12 символов A-Z0-9

Таким образом, в принципе никто не использует UUID.Есть ли причина для этого - не изобретенные здесь, более умные алгоритмы внутреннего идентификатора или что-то еще?И в моем случае, при отсутствии какого-либо внутреннего алгоритма, имеет ли смысл использовать UUID?

Answer 1

Возможно, что у других перечисленных вами поставщиков есть свой собственный идентификатор или схема хеширования, позволяющая им выставлять меньшее число при использовании чего-то более сродни внутреннему UUID.Но, в конце концов, нужно задать вопрос: если ваши URI предназначены для использования кодом (клиентами API), а не людьми, почему это имеет значение?

Не слишком волнуйтесь из-зачто сделали те продавцы.Нет гарантии, что (а) они поступают «правильно» и (б) их потребности совпадают с вашими.

Продолжайте и используйте UUID.

Answer 2

Я думаю, вы могли бы рассмотреть четыре основных варианта:

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

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

3. создайте столбец альтернативного ключа в таблицах базы данных для хранения значений de UUID.

4. вместо использования UUID вы могли бы иметь криптографические идентификаторы, сгенерированные на лету с использованием пользовательского начального числа для каждого клиента и исходного PK. Этот подход накладывает больше накладных расходов на выполнение, но может быть интересен в некоторых сценариях. Клиент должен будет использовать всегда зашифрованные данные, поскольку у него никогда не будет доступа к начальному или алгоритму.