Разработка первичного ключа REST API MySQL

Мы создаем новый REST API и должны принять несколько решений относительно первичного ключа и idempotency_key. У нашего API много пользователей, и пользователям разрешено искать только те объекты, которые им принадлежат. Запросы аутентифицируются, поэтому мы знаем, что userId связан с данным запросом.

Обеспокоенные свойства:

• userId Идентификатор пользователя.
• idempotenyKey Ключ идемпотентности, используемый в идемпотентных запросах к API. Уникальный для каждого пользователя.

Предположим, существует гипотетическая таблица Cars с конечной точкой GET .../cars/{id}, на которой мы будем основывать наше обсуждение.

Параметры

Вариант 1. Используйте сочетание userId и idempotencyKey в качестве первичного ключа

CREATE TABLE Cars (
 userId VARCHAR(255) NOT NULL,
 idempotencyKey VARCHAR(255) NOT NULL,
 description VARCHAR(255),
 PRIMARY KEY (userId, idempotencyKey),
 INDEX user_index (userId)
);

Поиск товара: GET .../cars/{idempotencyKey}

Мысли:

• Идентификатор, используемый при поиске, можно угадать.
• Поскольку объекты аутентифицированы, это, похоже, не представляет непосредственной проблемы безопасности, но это означает, что если когда-либо в API есть конечная точка, которая позволяет пользователю нашего пользователя что-то искать, мы должны предположить, что поиск можно угадать.

Вариант 2 - Использование хеша userId + idempotencyKey в качестве первичного ключа

CREATE TABLE Cars (
 id VARCHAR(255) NOT NULL,
 userId VARCHAR(255) NOT NULL,
 idempotencyKey VARCHAR(255) NOT NULL,
 description VARCHAR(255),
 PRIMARY KEY (id),
 INDEX user_index (userId)
);

При вставке рассчитывали id = hash(userId + idempotencyKey).

Поиск товара: GET .../cars/{id}

Мысли:

• Первичные ключи невозможно определить.
• Это дополнительно предотвращает возможность угроз безопасности при операциях с ids.
• Больше не составной первичный ключ.
• В отличие от варианта 3, не требует уникального ограничения на (userId, idempotencyKey).

Вариант 3 - Генерация первичного ключа uuid

CREATE TABLE Cars (
 id VARCHAR(255) NOT NULL,
 userId VARCHAR(255) NOT NULL,
 idempotencyKey VARCHAR(255) NOT NULL,
 description VARCHAR(255),
 PRIMARY KEY (id),
 INDEX user_index (userId),
 CONSTRAINT unique_by_user UNIQUE (userId, idempotencyKey)
);

При прошивке ставили id = UUID.randomUUID().

Поиск товара: GET .../cars/{id}

Мысли:

• id абсолютно непостижим и не привязан к каким-либо бизнес-данным.
• Требуется дополнительный индекс.

Вариант 4 - автоматически увеличиваемый первичный ключ, который никогда не открывается пользователю

CREATE TABLE Cars (
 id INT NOT NULL AUTO_INCREMENT,
 userId VARCHAR(255) NOT NULL,
 idempotencyKey VARCHAR(255) NOT NULL,
 description VARCHAR(255),
 PRIMARY KEY (id),
 INDEX user_index (userId),
 CONSTRAINT unique_by_user UNIQUE (userId, idempotencyKey)
);

Есть несколько способов выполнить поиск. Поиск может быть основан исключительно на idempotencyKey, то есть: GET .../cars/{idempotencyKey}

В качестве альтернативы мы могли бы автоматически сгенерировать uuid referenceId, который будет индексироваться и использоваться для поиска.

Мысли:

• Первичный ключ никогда не открывается пользователю, что является довольно распространенной практикой.
• Обеспечивает большую гибкость при изменении бизнес-логики (хотя для фундаментальных концепций, таких как userId и idempotencyKey, я не вижу, как они изменятся).
• Первичный ключ - это INT, поэтому он меньше. Это позволяет использовать меньшие индексы и, возможно, большую производительность.
• Снова требуется дополнительный индекс.

Ищу совет, какой подход выбрать. Очень важно учитывать производительность и масштаб.

Спасибо!