データストア内のエンティティのKey値を、レコードをプルアップするためのURLの一意の識別子として使用しています。
http://mysite.appspot.com/myaction/1x7s3fgdlbnRlcklkcicLAbcXc2VyQWNjb3VudCIFYW9uZ
これはあまり魅力的なソリューションではなく、SEOにも適していませんが、App Engine/Javaでエンティティを一意に識別するための最も簡単な方法です。
ただし、私の主な懸念事項は、エンティティの一意のキー値の表示に関連するセキュリティ上の懸念があるかどうかです。
エンコードされたキーには、アプリID、名前空間（存在する場合）、エンティティの種類名、およびキー名またはIDが含まれます。ここには2つの考えられる問題があります。その情報の開示（おそらく問題ではない）と、エンコードされたキーを受け入れているという事実です。渡されるキーで指定されたエンティティが正しい種類であり、ユーザーがそのエンティティにアクセスできる必要があることを確認しないと、ユーザーが独自のキーを渡して、開示してはならない情報を開示する可能性があります。 。
ただし、ほぼ普遍的には、フェッチするエンティティの種類名をすでに知っているので、キー名またはキーのIDだけを使用して、オンデマンドで完全なキーを作成することをお勧めします。これにより、URLがよりクリーンになります。
セキュリティ上の懸念は、潜在的なハッカーがデータベースについて少しでも知っていることです。
データベースの一部が危険にさらされた場合、エンティティIDがハッカーに役立つ可能性があります。
あなたと同じように、データベースIDを表示するのはあまり好きではありませんが、アプリケーションを適切に保護すれば、エンティティIDが役に立たないことを知っているので、心配する価値はありません。
それが実際の鍵だと思いますか？見た目は1つではありません（base64以外のデータには、通常、アプリIDが含まれています）。
ただし、ドキュメントにはそれが含まれています。
注：文字列でエンコードされたキーは、生のキーデータに変換して戻すことができます。これにより、他のキーがわかっている場合に、他のキーを簡単に推測できます。文字列でエンコードされたキー値はURLに安全に含めることができますが、アプリケーションは、キーの推測可能性が問題にならない場合にのみ含める必要があります。
次のようなことを行う方がはるかにクリーンです。
foo = FooModel.get_by_id(int(foo_id))
攻撃者がIDを推測するのを防ぐことはできませんが、少なくともIDが「不透明」であると思わせることはありません（base64-protobufをいじくり回す代わりに、IDを簡単に変更してアクセス制御をテストできます。 -エンコードされたデータ）。
私の意見では、これはセキュリティ上の懸念事項ではありません。多くのサイトでは、サイト内の識別子としてidを使用しています。キーはデータベーステーブルの行への単なるキーであり、テーブルやユーザーアカウントなどの観点からデータベースに関する詳細を表示することは控えたいと思います。
この点で、データベースエラーが発生したときにサイトがデータベースエラーをダンプすることを禁止し、それらをキャッチして適切に処理する必要があります。