プロジェクト始動！
ある日、あなたは新しいWebプロジェクトの開発担当に任命されました。
テーマは「旅行・観光情報サイト」。世界中の観光地を紹介し、ユーザーが旅の計画を立てられるようにするのが目的です。
設計に取りかかろうとしたあなたは、ふと立ち止まります。
「このサイト、どのようなURL構成にすればいいんだろう？」
学ぶこと：階層構造とフラット構造
今回は、階層構造とフラット構造を学びましょう。
- 階層構造：文脈が明確、整理しやすい。ただし、URLが長くなりやすい。
- フラット構造：短くてシンプル。文脈が失われ、衝突しやすい。
概要は以上！このあともう少し説明します！
国→都市→観光地：階層構造で考える
まずは基本の構造を整理しましょう。
旅行サイトでは、地理的な階層が自然に存在します。
＜モデル構造＞
- 国（country）
- 都市（city）
- 観光地（spot）
この関係をURLで表すと、以下のようになります。
/countries/japan/cities/kyoto/spots/fushimi-inari-taisha
※japan、kyoto、fushimi-inari-taishaの部分は可変です。
なぜこの順番？
- 地理的な包含関係（国→都市→観光地）
- ユーザーの探索順序と一致
- URLを見ただけで「どこにある何なのか」がわかる
- ログ解析やアクセス制御にも便利
観光地の画面を設計する
京都市にある観光地の一覧を表示する画面がほしい。
伏見稲荷大社の紹介ページもほしい。
管理者が観光地情報を編集する機能も必要だ。
以下にしました。
＜一覧画面（都市内の観光地）＞
/countries/japan/cities/kyoto/spots
＜詳細画面（選択された観光地の紹介）＞
/countries/japan/cities/kyoto/spots/fushimi-inari-taisha
＜編集画面（管理者用）＞
/countries/japan/cities/kyoto/spots/fushimi-inari-taisha/edit
企画部門から新たな要望が！「ツアー機能を追加したい！」
数週間後、企画部門から新たな要望が届きました。
「複数の観光地をまとめて紹介する“ツアー”機能を追加したい！」
ツアーのURL：フラット構造で考える
ツアーは、京都・奈良・大阪の名所をまとめたような「横断的な構造」です。
階層構造に組み込むと複雑になるため、フラット構造で検討します。
ゴールデンルート（東京→京都→大阪）のツアー紹介ページ！
/tours/golden-route
関連ページのリンクも考える
ツアーに含まれる観光地のページやレビューページも必要そうだ。
＜関連リンク＞
/tours/golden-route/spots/tokyo-tower
/tours/golden-route/spots/kinkakuji
/tours/golden-route/spots/osaka-castle
＜レビューページ＞
/tours/golden-route/reviews
補足
どうやら無事、設計が進んでいるようですね。
補足事項を記載します。
・スラッグとIDの使い分け
スラッグとは、URLの一部として使われる「人間が読める識別子」のことです。
通常は英数字で構成され、スペースや記号を含まず、リソースの名前やタイトルを簡潔に表します。
| リソース | スラッグ例 | ID例 | 選び方 |
|---|---|---|---|
| 国 | japan |
JP |
スラッグで十分 |
| 都市 | kyoto |
city-123 |
スラッグでSEO・可読性向上 |
| 観光地 | fushimi-inari-taisha |
spot-456 |
スラッグ推奨、ただし重複注意 |
| ツアー | golden-route |
tour-001 |
スラッグでブランディング効果あり |
・拡張性を考える
将来的にレビュー機能やタグ機能を追加するなら、リソース単位で拡張できる設計が理想です。
/spots/fushimi-inari-taisha/reviews
/tours/golden-route/tags/spring
まとめ
- 階層構造は「文脈」を伝える
- ツアーのような横断的リソースはフラット構造が適している
おや？次はフロントエンドとAPIに分割して、より利用者に訴求する画面や構成を検討しているようです。
それはまた今度、一緒に考えましょう！