WEBアプリケーションフレームワーク(主にPHP)のルーティング処理について (never まとめ)

とくにまとめられてないメモ書きです。とくに主張とか結論はないです。(あ、Hello Worldベンチマーク?プギャーm9(^Д^) は言わずもがなです )

前提:主にPHPではURLとアクションのマッピングについて上から順に以下のような変遷をたどってると思います(そうじゃないって突っ込みはいっぱいあるでしょうが)

  • オールドスクール

    /foo/module.php?key=var

  • 命名規則

    /controller/action/ => class Acontroller { function action(){ $parameter = func_get_args(); }}

  • 宣言型

    $router->add('/controller/action/{:param}', $actionName)

命名規則型がやっかいな一例はこういう所です

<?php

class PostController
{
    function readAction($id)
    {
        if (!is_int($id)) throw new InvalidArgumentException("id shoud be integer");
    }

}

Ver1時代のベンチマークとの関わり

またルーティング処理は、フレームワークそのものと密接な関係でもあり、ベンチマーク処理の部分では Ver1世代から焦点でもありました。

(※ デフォルトのZF1では、addRouteはindex.php書かないということです)

ZFでの変遷

ルーティング処理についての、ZFの変遷やPros/Consについては、Ben Scholzenのスライドが詳しいです。

マイクロフレームワーク

マイクロフレームワーク/ミニマムフレームワークは色々でましたが *1 特にBulletはネストされるルーティングとなっており面白い構造だとおもいます。

Fast!Fast!Fast!

ルーティングだけを処理機能としてみた場合、拡張モジュールで書かれたから早いぜっていう主張もあったりしますが、 nikicに突っ込まれてたりもします。

認証・認可

ルーティングが終わったらレスポンスを返せるという訳ではありません。認証と認可がかかわります。 認証だけならログインチェック後 /user/loginにリダイレクトすればいいだけかもしれません。 ですが認可となると、どのリソースにアクセスできるかも判定が必要です。

ここでkazuhookuさんが突っ込まれてるアクセス権はModelレイヤで処理するのが王道では?に同意します。

私の関心ごとの一つは「ログインはされてるけど、リソース全てにアクセス権がなかったユーザがリクエストを送ったときは?」 などのケースです。(私が言ってるリソースというのは、たとえば風俗サイトで有料オプションAユーザがバストサイズを知れる。有料オプションDユーザが顔写真を見れる。とかを想定しています)

その他

PHP以外も踏まえてWEBアプリルーティングに着目しての考察記事・論争っていうのをさがそうとしましたが、上手く見つけられませんでした。

他にもヴァリデーションにてfalse時にフォワード・リダイレクトはみたいな関心事項もあると思います。その点、こういうアプローチもあるのではという記事も書きましたがツッコミはいただいておりません。

....え、何?RESTについては?

関係のあるかもしれないツイート

参考

OrePHPはシンプルで速いクールなフレームワーク