RESTfulなURLの一意なIDとして何を使うべきか

初めまして。booinkと申します。

みなさんがどのように解決しているのか気になったため投稿いたします。

Railsを素のまま使うと、モデルに紐づいたテーブルのauto_incrementなIDがURLのリソースのIDとして使用されますが、auto_incrementなIDは他のリソースが特定しやすいため、避けられる傾向にあると思います。

今までは、例えばslug文字列をテーブルのカラムに持たせてリソースの特定に使用したり、uuidカラムを別途追加またはidをstringにして、SecureRandom.uuid等の値を持たせる方法で解決してきました。
gemで言えば、friendly_id(https://github.com/norman/friendly_id) や uuidable(https://github.com/flant/uuidable) などを使用しております。

ただ、デファクトスタンダードと呼べるような方法が上記にあげた解決方法なのかどうか自分の中で疑わしかったので、みなさんはどのように解決しているのか気になった所存です。

今回投稿するに思い立ったきっかけとして、fast_jsonapi(「Sorry, new users can only put 2 links in a post.」エラーが出てしまったので、割愛します) を使ってモデルのデータをシリアライズしようとした時に、モデルのrelationshipsに(auto_increment な) idしか指定できず、別途追加してある uuid 文字列をidの代わりに指定しようとすると、一度関連先のモデルをfindしてからuuidの値をアサインする形になってしまうため、冗長かつSQLが多く発行されてしまうのを懸念して、uuid文字列をテーブルのprimary_keyとして再構築しようかと考えましたが、文字列のprimary_keyにやや抵抗があるため、どうしたものかと頭を抱えている現状でございます。

勢いで綴っているため乱文ではございますが、皆様のご意見をお伺いしたく思っております。

なにがデファクトなのかは僕もわからないのですが、uuidを使うのは一般的な解決策だな、という気がします。

ただidを普通に使っている状態でuuidに切り替えるのが面倒、という状況では hashid-rails を使って手軽にそれっぽいhash文字列を都度生成したりしています。

他の方はどんなやりかたでやってますか?

返信ありがとうございます。
やはりuuidでなんとかするのが一般的ですかね。

実は投稿するのと並行して、IDを可逆的にハッシュ化してActiveRecordのfindを上書きするgemの構想を練って実際に作っていたのですが、作っている途中でhashid-railsを見つけてしまい、hashid-railsの方がハッシュ値文字列が短くて有能そうだったので、頓挫していました(笑)