この男の言うことに基づいて: http://toddfredrich.com/ids-in-rest-api.html
彼がUUIDを使用してAPIリソースを識別することについて正しいと仮定します。それから私はそれをそのように実装しようとする問題に遭遇します、これは:
class FooEntity {
final String id = null; //auto-generated by my backend (mongodb), not shared
final UUID uid = UUID.randomUUID(); //the resource id
}
(クライアントとサーバーの間では、データベースエンティティではなく、送受信されるDTOが送信されます。)
現在の問題は、id
はもう使用していないため、役に立たないということです。クライアントはuid
を使用してリクエストを行うので、なぜ2つのIDを処理する必要があるのですか?次に、最初の同じ問題に戻ります。 UUIDを主キーとして設定した場合(_id
)次に、バックエンドIDを公開しています。
そのほかに、効率のトピックがあります。 ObjectIdによるインデックス付けはUUIDよりもはるかに効率的であると読みました。
バックエンドIDを公開しています
エンティティがリクエストを通じて返されたときに、エンティティを識別するために他にどのような手段がありますか?これは、SSNまたは同様の識別子よりも完全に合法で安全です。それはトッドが話していることです-識別技術とエンティティを中立にすることと彼は正しいです。
効率のトピック
ObjectIdの方がはるかに効率的である場合は、両方の識別子を保持できます。理論的には、データベースの自動インクリメンタよりも常に 識別子にUUIDを使用 の方が適しています。
いいえ、データベースに関する限り、内部構造は外部APIに公開されていません。 IDには情報がありません。彼らは現実の世界でさえもユニークではありません。 ID:47はどこにでもあります。アクセスできるエンティティがあり、データを操作できる可能性がありますが、このデータベースがすべてを1つのテーブルに格納するか10に格納するか、インクリメンタルIDをPKとして使用し、FKに関連するかは決してわかりません。
可能であれば、GetUserAccountByID(12345)は、誰かにGetUserAccountByID(12346)を試すように要求しています。他のセキュリティ対策が原因で機能しない場合でも、アカウント:12346に関する情報を求めて会社をソーシャルハッキングしようとしないでください。DBAに電話して、2週間待つことをいとわない場合は、応答;)
そのため、GUIDを作成しますが、電話番号や電子メールアドレスなどの適切なキーまたはその他の自然なキーを作成します。テーブルのフィールドに一意の制約を設定して、データのマージの試行で不明瞭なコピーアンドペーストの試行を回避します。
これは冗長ではありません。 2つのフィールドの目的は異なります。
効率IDとUUIDについては、それぞれ数百万のレコードを持つ複数のテーブルを含む複数の結合がない限り、それほど大きな違いはありません。 UUIDを使用すると、サーバー側で適切にチェック/適用しないと、アプリケーションをスクラップすることがはるかに困難になります。
IDを使用すると非常に簡単です。代わりにUUIDを使用すると、スクラッパーのオプションが1つ少なくなります。
IDは、アプリケーションのデータベースインスタンスの内部で何かと見なすことができます。その文には3つの重要な単語があります。
個人的な好み:シンプルなIDと一意のビジネスID(メール、ログインなど)を使用することを好みます。したがって、データを交換する必要がある場合は、ビジネスIDを使用します。これは、ターゲットシステムがUUIDを処理しない可能性があるためです。