ROAに準拠できない（しづらい）シチュエーションを列挙してみる
ROAに準拠したWebアプリを作りたいのに、準拠できない or 準拠しづらいシチュエーションってありますよね？ 私はあります。それを列挙してみようという試みです。
なお、「ROAに準拠している＝ROAの4つの特性を満たしている」という等式を前提とします。これに納得できない方は、もう自分で考えればいいじゃない！
ROAの4つの特性
ROAには4つの特性があります。
- アドレス可能性
- ステートレス性
- 接続性
- 統一インターフェイス
詳細はid:ikasam_aさんの「ROA と Catalyst」をご参照ください。
ここからが本題。各特性について、「準拠できない（しづらい）かも」というシチュエーションを考えてみます。
アドレス可能性
Ajaxアプリだと準拠しづらいですね。たとえばAjaxベースのウェブメールで、メール検索結果にURIが割り当てられていなければ、その検索結果はアドレス不可能です。アドレス可能にするためには、Googleマップの「このページのリンク」のような仕組みを用意するなど、何らかの考慮が必要になります。
ステートレス性
CookieにセッションIDを保存するだけで違反してしまう憎い奴なわけですが、フォーム認証が主流な現在、Basic認証とかDigest認証とかその他モロ師岡をWebアプリで採用するのは厳しい。山本陽平さんのおっしゃるように「便利な必要悪」と妥協するのが、精神の健康のためにはよいのではないでしょうか。
また、RESTful本に出てくる例では、アプリケーションキーでリクエスト回数を制限する場合もステートフルにせざるをえません。「当日何回リクエストしたか」はアプリケーション状態なのでクライアント側で維持するのが理想なんですが、世の中、私のようにお人好しばかりではないので、虚偽申告するクライアントが続出すること間違いなしです。結局、ステートフルにせざるをえない、と。
接続性
これは準拠できるでしょう。接続性かわいいよ接続性。
統一インターフェイス
私がROA提唱者をREST過激派とみなしている所以がこれ。オーバーロードPOSTを使わなければやってられないシチュエーションなんていっぱいあるじゃん！
- クエリが長すぎてGETが無理な場合
- これもオーバーロードPOSTを使うしかない（HTML・UA・Webサーバの制約）。
おわりに
ここまで考えて、私の頭はスッカラカンになってしまったわけですが、ほかに「こんなシチュエーションでもダメだよね？」とか「あれを見落としてるんじゃないの？」とか「ブログのタイトルださくね？」とかいったご意見があれば、ぜひお教えください。よろしくお願いします！
