URL設計（BaseURL/Baseパスを意識しよう）
画面定義に合わせてURLの一覧を作成していく場合
MVCフレームワークを使った開発の場合、一般的に [BaseURL]/コントローラ名/アクション名 といったURL設計をしていきます。 ここで登場した BaseURL について意識すべきことをまとめます。
BaseURL
BaseURLとは BaseURL = URLスキーム＋:// + FQDN + / + Baseパス
簡単にいうと、ローカルのapacheなどで開発する場合は、
を指します。website/があったりなかったり。
URLスキームとFQDNはよく意識されるのですが、Baseパスについて考慮漏れがあり、途端に対策に追われることがあります。 このBaseパスについて次に説明します。
Baseパスの問題
開発初期の段階で、Baseパスを意識すること、しないことで、開発に大きな影響を与えます。
クライアントの予算や、意識の違いなどもあるのですが、本番サーバー以外は準備してくれない、というのも珍しくありません。
開発環境や、テスト環境として、独立したサーバーを準備できる場合、Baseパスは無しになりますが別の開発環境と相乗りをする場合、このBaseパスを意識する必要がでてきます。
document_root直下に配置する想定だったのが、テスト環境やお客様の確認用の環境ではdocument_rootの下にたくさんのサイトのフォルダが区切られいて、そのフォルダに配置することを強制されることがあるのです。
html内のcssや、javascriptのURLとして "/"からはじまる絶対パスをハードコーディングしていた場合、途端に破綻します。
に配置されるはずのファイルが
となり、cssなどがNotFound状態になります。
Baseパスが環境によって変わる場合の対策
リソースのURLは相対パスにする。（非推奨）
URLの階層の変化に絶えられないのでオススメしません。
/Controller名/Action名
というURL設計をするのが一般的ですが、Action名がindexの場合、indexは省略可能というルールを設けている場合があります。 ※CakePHP/.NET MVC 他
例として以下のURLを考えます。
/user/index
indexは省略可能なので、
- /user/index
- /user/
- /user
この3つは全てUserControllerのIndexActionにルーティングされてしまいます。
/user/index 、/user/ については同じ階層と認識されますが
/user は一つ上の階層になっています。
つまり、リソースの位置を相対パスにすると、こういう階層の変化に耐えられないのです。 indexは利用しないという独自ルールを設けることもできますが、リリース後の保守などを他のベンダーがすることもあるので、独自ルールは避けたいところです。
フレームワークの機能を利用する
フレームワークによっては、css/javascript/imgなどのリソースは直接に記述せずに、viewに準備されているfunctionを利用して出力することで、BaseUrlが自動的に挿入することができます。
つまり、初期の段階で、これらを開発者に意識させるのです。きちんとリソースのパスががfunction経由で出力されてることをコードレビューなどで拾うのがいいのですが、わざわざコードレビューで拾い切るのも大変なので、全ビューをスキャンして正規表現などで、直接リソースのパスが記述されている箇所を捜索するプログラムを実装しておくのもアリかと思います。
Baseパスを意識しなかった場合の裏技解決案（非推奨）
サイトの相乗りについて、解決策が無いわけではありません。 ポートを分けてポートフォワードをする、localにhostsを書いてdomainを自作して、domainによってdocument_rootを切り替えるなど手はあります。
ただ、お客様の全ての環境にhosts書けますか？とか。hostsを書くなら開発環境、テスト環境にとどめておいて、ステージング、レビュー環境などでは小細工なしで表示させる必要が有ります。
担当しているクライアントのPCにhostsを置かせてもらって動作検証してもらっていたら、いきなり、 開発をまったく知らないクライアントの重役から電話がかかってきて、「俺のPCだと表示されない！大問題だ！」とか、火消しに時間を取られることもあります。
BaseURLは、プロジェクト後半で、後から差し込むと大騒ぎになりますが、初期の段階で一旦ルールを作成しておくと、プロジェクトがスムーズに進むと思います。
