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

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

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

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

ОТВЕТЫ

Ответ 1

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

Не слишком волнуйтесь, что сделали эти продавцы. Там нет гарантии, что (а) они делают "правильную" вещь и (б) что их потребности такие же, как у вас.

Идем дальше и используем UUID.

Ответ 2

Думаю, вы можете рассмотреть четыре основных варианта:

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

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

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

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