Web屋のネタ帳

CoolなURLを作るには（ギークなお姉さんは好きですか 2008/7）

完全に甘く見ていた。「変数をごにょごにょすればできるっしょ＾＾」とタカをくくっていた。 ぜんぜん違う。そんな小手先の修正じゃダメだ。

うん。言葉が適当かわからないが、気づく、違うということに気づく、表面じゃない根本的な何かに気づく、のは重要なことだ。

URLと動的/静的なページとの関係と影響についてはこのブログでも何年か前に取り上げたことはあるが、より具体的な方法については書いたことがほとんどない。なぜならググれば他で出てくることだから。

がしかし、いつまでたってもmod_rewriteだのPATH_INFOだのの小手先テクニックの話が出てくるだけで、Webサイト自体の拡張性をも見据えた全体設計の中のひとつとしての「coolなURI」の作り方はどうあるべきなんだろう？という話は一向に出てこない。

俺それ知ってるぜ、なんておこがましい自信はまったく無いし答えはひとつじゃないはずだけど、全体から見てどうあるべきなのというところから考えたほうがあとあといいことあるよ、とは気づいてるつもりだ。

話がそれるけど、

ギークなお姉さんは好きですか ギークはベストなコードを目指すべし！

URLがモロパラメータ丸出しだけど
こんな風にできたらCoolだと思います。

http://geekdb.jp/geek.php?id=1
↓
http://geekdb.jp/geek/yusukebe

間違いない！ちょ、これ早急に実装せねば(｀･ω･´)

?も=もいくないよ！(2003/10)と叫んでも「ポカーン」とされていた時代の筆者と比べると、Coolだね！の一言で通じる今の世代がうらやましいぜ。

われながら相変わらず前置きが長い。まあいいや。

目標

http://geekdb.jp/geek.php?id=1
を
http://geekdb.jp/x/geek/foo
にする。（fooは1でもかまわない）

「x」がポイントだ。いや、確かに邪魔かもしれないが、シンプルさと作りやすさとわかりやすさとセキュリティを与える意味で実は重要な妥協である。

apacheの設定をちょっといじる

    AllowEncodedSlashes On
    <FilesMatch "^x$" >
        ForceType application/x-httpd-php
    </FilesMatch>

mod_rewriteは使わない。mod_rewriteが100%悪だとは言わないが、あれはやはり麻薬だ。 便利だと思って使いすぎて、rewrite設定が数十、数百ステップにおよんでしまってもはやそれは設定ファイルなのかソースコードなのか区別がつかず、もう誰もメンテできない、なんていう話はザラにある。

なお、AllowEncodedSlashes は無くても動くが、スラッシュなどの記号がURLエンコード(%2F)されてGETパラメータに入るときに必要となる。

ファイル「x」をつくる

ファイル名はx.phpではなく、x。 yでもzでもいいけど、お好みで。短いほうがいいでしょ？

<?php
$args = explode("/",$_SERVER["REQUEST_URI"]);
switch ($args[2]) {
    case "geek":
        include("DocumentRootじゃないどこか/geek.php");
    case "book":
        include("DocumentRootじゃないどこか/book.php");
    default:
	header("Not Found", TRUE, 404);
        echo "ねーよ";
        exit(0);
}
?>

なお、ファイルxには

<?php include("DocRootじゃないどこか/x.php"); ?>

とだけ書いて、x.phpのほうにさっきの内容を書く、というのでもいいかもしれない。 拡張子なしのファイルは何かと扱いにくいしね。

以上で、
http://geekdb.jp/x/geek/foo
へのアクセスは、
$args[3] に"foo"が入る。あとは好きに料理できる。

ついでに言うと、
http://geekdb.jp/x/geek/foo/bar/a/b/?c=3&d=4
へのアクセスは、
$args[1] は"x"
$args[2] は"geek"
$args[3] は"foo"
$args[4] は"bar"
$args[5] は"a"
$args[6] は"b"
$_GET["c"]は"3"
$_GET["d"]は"4"
になる。

ポイントは３つ。

1. 設定ファイルは1行でも短いほうがいい。（ここではapacheの）
2. DocumentRootに余計なものを置かないほうがいい。
3. どうせならMVCを根本から実践してみるのもいい。

1. (apacheの)設定ファイルは短いほうがいい

これは人によってポリシー違ってくるとは思うけど、少なくとも筆者は、 設定ファイルに長ったらしく妙なロジックを詰め込むのは極力避けたほうがいいと考えている。 apacheの設定に限らず、どんなソフトウェアどんなアーキテクチャであれ、 ロジックを詰め込むのはphpなりjavaなりperlなりそのサイトが基準とする言語のソースコード上だけでたくさんだし、バージョン管理/ビルド管理の対象ジャンルをいたずらに増やさないほうがあとあと管理が楽だし。 （JavaのDIコンテナと設定ファイルの関係はあれはあれで話が複雑になるので別んとこでやってくれ）

その意味で、夢も設定も無駄に膨らみがちなmod_rewriteの多用はあえて避けている。また、特殊なことをする対象を「x」ひとつに絞っている。geek.php をgeekに、book.phpをbookに、、、と考え出すと考えた数だけ設定が増えちゃう。

2. DocumentRootに余計なものを置かないほうがいい

この方法だと、極端な話DocumentRootに置くべきものはxだけである。 あとは画像と*.cssと*.jsくらいか。 Webサイトが膨らんでくると、古くてもう使わなくなったクラスファイルとかjsp/phpとかが出てきて、そしてほったらかしになるものだが、上記の方法だとxの内容さえちゃんとメンテしていれば、古いスクリプトが残っていてもセキュリティリスクは小さくなる。

3. どうせならMVCを根本から実践してみるのもいい

察しのよい人は冒頭のURLとソースの例を見ただけでお気づきだろうが、 「x」はMVCの概念(Model, View, Controler)で言うところのCだと考えることもできる。 CoolなURLを作ろうと思うとCoolな概念に出会う。 答えはひとつだけなわけじゃないけれど、でも結局Coolの目指すところ行き着く先は、同じだ。

see also:

• 動的ページと静的ページ(1) 一般論 (2004/10)
• URLを変えるな！(1) － 後悔しないためのWebデザイン (2006/10)
• 良いURLについて考える - builder by ZDNet Japan (2008/1)
• 画像もDBに格納して管理する話とCoolなURLの作り方の話をまとめて補足。 (2008/7)
• CoolなURLを作るときのHotな落とし穴 (2008/8)