В традиционных базах данных SQL было очень распространено использование первичных ключей автоинкремента. Позже, в эпоху кластерных баз данных, это привело к проблемам коллизий, поскольку другой узел кластера мог установить тот же идентификатор, который уже был установлен на другом узле миллисекунды назад. Существуют различные методы, чтобы избежать этого, но если вы используете подход ORM для доступа к вашему хранилищу, идентификаторы автоинкремента создают другую проблему. Когда вы создаете новый экземпляр сущности, у него нет идентификатора, пока он не будет сохранен в базе данных. Строго говоря, ваша модель на данный момент недействительна. Он не содержит, пожалуй, самого важного обязательного атрибута. Еще одна причина, по которой вы не хотите использовать целочисленные идентификаторы, заключается в том, что таким образом в вашем REST API вы можете раскрыть свои бизнес-секреты, такие как количество клиентов или что-то в этом роде.
Для этого есть несколько решений, но наиболее распространенным кажется использование UUID (RFC 4122). Универсальный уникальный идентификатор, сокращенно UUID, иногда также называемый GUID или Globally Unique Identifier, гарантированно будет уникальным, поскольку он зависит от нескольких случайных факторов, таких как время, MAC-адрес и т. д. Поскольку UUID содержит только шестнадцатеричные символы и дефисы, он безопасен для URL, но он довольно длинный, 32 символа без дефисов. Поэтому, если у вас есть несколько из них в URL-адресе (например, запрос REST GET), это значительно увеличит строку. Так что было бы неплохо сделать его как-то короче, и, как обычно, мы можем подумать об использовании некоторой кодировки. Вот пример UUID:
fed23a8d-f046-44a1-bcf1-276dedb91e6f
Мы уже знаем, что Base62 безопасен для URL, но, похоже, он не является отраслевым стандартом. Будем надеяться, что вариант Base64, описанный в RFC 4648, также безопасен для URL. Вкратце описано, что вместо использования + и / в результирующей строке используются - и _ соответственно, а символ заполнения = пропускается. Но давайте посмотрим код:
Как видно из примера, пакет стандартной библиотеки Go base64 поддерживает безопасную кодировку URL-адресов, так что делать особо нечего. Вот также пример вывода:
Original UUID ee659c52-607d-46c5-8f4b-73d90b10afa4 URL safe encoded 7mWcUmB9RsWPS3PZCxCvpA Decoded UUID ee659c52-607d-46c5-8f4b-73d90b10afa4
Итак, мы получили закодированный UUID длиной 22 символа, который мы можем смело использовать в наших запросах REST GET. Ваше здоровье!
