Я создаю приложение SaaS и хочу предоставить идентификаторы для ресурсов, которые не привязаны к моей текущей реализации хранилища данных (идентификаторы автоинкремента Postgres). Эти сообщения о переполнении стека (один два) предполагают, что создание локально уникальных идентификаторов сложно, и я мог бы также используйте UUID, которые, конечно, легко и безопасно сгенерированы практически на любом языке.
Я доволен этим подходом, но мне интересно, почему я не могу найти какие-либо API от крупных SaaS/размещенных игроков, которые делают то же самое? Например:
Так что в основном никто не использует UUID. Есть ли причина для этого - не изобретенного здесь, более умных внутренних алгоритмов ID или чего-то еще? И в моем случае, при отсутствии какого-либо внутреннего алгоритма, имеет ли смысл использовать UUID?
Возможно, что у тех других поставщиков, которые вы указали, есть свой собственный идентификатор или схема хэширования, чтобы позволить им показывать меньшее число при использовании чего-то более похожего на UUID внутри. Но, в конце концов, нужно задать вопрос: до тех пор, пока ваши URI будут потребляться кодом (клиентами API), а не людьми, почему это имеет значение?
Не слишком волнуйтесь, что сделали эти продавцы. Там нет гарантии, что (а) они делают "правильную" вещь и (б) что их потребности такие же, как у вас.
Идем дальше и используем UUID.
Думаю, вы можете рассмотреть четыре основных варианта:
используйте UUID в качестве основных ключей базы данных, но это может быть более вычислительно дорого, чем использование Long
создать слой UUID to Long, таким образом, вы можете публиковать свои ресурсы REST, но поддерживать чистую структуру базы данных с помощью Long PK
создайте столбец альтернативного ключа в таблицах базы данных, чтобы сохранить значения UUID.
вместо использования UUID вы можете иметь криптографические идентификаторы, созданные на лету, используя пользовательское семя для каждого клиента и оригинальную PK. Такой подход накладывает дополнительные накладные расходы, но может быть интересен в некоторых сценариях. Клиент должен будет использовать всегда зашифрованные данные, поскольку у них никогда не будет доступа к семену или алгоритму.