バックエンドIDは公開するか、REST APIで公開しないか？

この男が言うことに基づいて：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に電話して、返事;）

したがって、GUIDを作成します。ただし、適切と思われるもの、または電話番号やメールアドレスなどの他の自然なキーを作成します。マージデータの試行で不明瞭なコピーアンドペーストを回避するために、テーブルのフィールドに一意の制約を設定します。

これは冗長ではありません。2つのフィールドは異なる目的を果たします。

効率IDとUUIDについては、それぞれが数百万のレコードを持つ複数のテーブルを含む複数の結合がない限り、これはそれほど大きな違いはありません。UUIDを使用すると、サーバー側で直接チェック/適用しないと、アプリケーションの廃棄がはるかに困難になります。

• GET [...] / 1
• GET [...] / 2

IDを使用する場合は非常に簡単です。代わりにUUIDを使用すると、スクレーパーのオプションが1つ少なくなります。

IDは、アプリケーションのデータベースインスタンスの内部的なものと見なすことができます。その文には3つの重要な単語があります。

• アプリケーション：モデルであるため、テーブルはそのアプリケーションでのみ使用される可能性が高い
• データベース：複数のアプリケーションが同じデータベースに対してそれを使用した場合は、問題ありません
• （データベースの）インスタンス：分散システムがある場合、idは互いに打ち解け、データベースのインスタンスを使用しない他のシステム/アプリケーションにとっては意味がありません。UUIDは、その特定のケースのソリューションです。

個人的な好みについて：単純なIDと一意のビジネスID（メール、ログインなど）が必要です。したがって、データを交換する必要がある場合は、ビジネスIDを使用します。ターゲットシステムはUUIDを処理しない可能性がありますが、ユニークなビジネスキーをうまく処理する可能性が高いからです。