2

私たちは新しい REST API を構築しており、主キーとべき等性キーに関していくつかの決定を下す必要があります。私たちの API には多くのユーザーがいて、ユーザーは自分に属するオブジェクトの検索のみが許可されています。userIdリクエストは認証されるため、特定のリクエストに関連付けられていることがわかります。

懸念される特性:

  • userIdユーザーの ID。
  • idempotenyKeyAPI へのべき等リクエストで使用されるべき等キー。ユーザーごとに一意です。

議論の基礎となる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}

考え:

  • ルックアップで使用される ID は推測可能です。
  • オブジェクトは認証されるため、これが差し迫ったセキュリティ上の懸念を引き起こすようには見えませんが、ユーザーのユーザーが何かを検索できるようにするエンドポイントが 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}

または、参照 ID uuid を自動生成し、インデックスを作成してルックアップに使用することもできます。

考え:

  • 主キーがユーザーに公開されることはありませんが、これはかなり一般的な方法です。
  • ビジネス ロジックが変更された場合の柔軟性が向上します (ただし、userId や idempotencyKey などの基本的な概念については、これらがどのように変更されるかわかりません)。
  • 主キーは INT であるため、より小さくなります。これにより、インデックスが小さくなり、おそらくパフォーマンスが向上します。
  • ここでも追加のインデックスが必要です。

どのようなアプローチを取るべきかについてのアドバイスを探しています。パフォーマンスとスケールに関する考慮事項は非常に重要です。

ありがとう！

4

0 に答える 0