User Generated ContentsサービスにおけるユーザーページURL
UGCサービスにおけるユーザーページのURLって、service.domain/usernameであることが多いけど、これはサービスで使うURLとも被ることがあるよね。そういう悩みを避けるためのURL構成ってどんなものがあるだろう?
ChatGPT o1曰く―
フォルダ分け
/u/username
/users/username
メリット
/users と機能ページが衝突しない
直感的に「ここはユーザーをまとめているセクション」と判る
デメリット
そこまで大きな欠点ではないものの、URLが長くなるのを嫌う人もいる
@
/@username
メリット
Twitter や GitHub のように、ユーザー名を判りやすく示す(たとえば github.com/@alice のような手法を使うサービスもある)
「@ がユーザーを示す」という認識が定着してきている
デメリット
一部のウェブサーバーやフレームワークで、@ を扱うときにURLエンコードなどのケアが必要な場合がある
/@foo を静的ファイルと混同するサーバー設定に遭遇する可能性がわずかにある
サブドメイン
username.service.domain/
メリット
URL自体がシンプルになり、ユーザーごとの独立感が出る
クッキーやキャッシュなどをユーザーごとに切り分けたい場合に便利
デメリット
DNSやワイルドカード証明書などの設定が必要で、運用がやや面倒
ユーザー名に無効なサブドメイン文字(ピリオドやアンダースコア)が含まれたら扱いにくい
モバイルアプリなどでサブドメインを扱う際に制限がある場合がある
スタイリッシュ直下
service.domain/username
Reserved words サービスURLが優先される
メリット
URL が最も短く、スタイリッシュ
デメリット
衝突を完全に防ぐには予約語の網羅が必要
後々サービスの機能が増えて、新たに /something が必要になったときユーザー名と衝突する可能性が出る
予約語が増えすぎると、ユーザー名が取得できない不満が出たりする