Ajax と REST

最近、レガシーな Web アプリ開発でも、Ajax を機能として取り入れよう...というのが、かなり具体的な案件として出るようになっています。本流の遷移は通常の POST メソッドによるレガシーな遷移で行うが、たとえば、「一覧表のソート順変更」「検索条件の変更」といった処理は、ＵＩとしては重要ですが、処理の流れとしては副次的なものとなります。そういう副次的処理を Ajax 部品に任せてしまう、としたら、流れが理解しやすく、メンテも楽なコードになることでしょう。

この時、重要なポイントがあるように思います。それが実は、REST と同じ結論になるので面白いと思うので書きましょう。「REST って何？」という方もいるでしょうが、これ最近かなり流行ってる Webアーキテクチャ・スタイルです。「REST ＝ SOAP や XML-RPC ではない簡単な Web サービス」というお考えの方もいるかもしれませんが、そういう方は定評のある山本陽平氏の「REST入門」をお読みになることを薦めます。この REST のポイントを乱暴にまとめてしまうと、

1. リソースは URI で特定する→だから PathInfo からリソースIDを拾い出すことが多い。ブログの permalink はこのやり方。
2. GET, POST, PUT, DELTE の「動詞」が HTTP では用意されているのだから、それを「正しく」活用する。GET はリソースの状態に影響を及ぼしてはならないが、POST はリソース状態の新規作成に限って使われなくてはならない。既存リソースの状態の変更は PUT メソッドだ。
3. URI情報はリソースを特定するためにあり、見かけの制御はクエリ文字列の担当にすべきである。→ URI はクライアントで操作すべきではない。（ＵＩを通じて）操作すべき対象はクエリ文字列に限定すべきである。
4. クッキーを使ったセッション管理は、HTTP 以外で状態を持ち込むから、REST ではない。REST はステートレスである（状態を内部で持たない）。

といったあたりが重要なポイントでしょうか。まあ、勿論レガシーな Web アプリはこの原理に従っていないのが普通でしょう。Webアプリ＝セッション管理付き、というのがこれまでは常識でしたし。ですから、REST がそのまま既存の Web アプリのすべてに革命的な影響を与える...とまでは言えないものなのですが、それでもアイデアとして気に留めておいた方がよいポイントがあるように思います。

それは、

「GET と POST のメソッド、クエリ文字列とコンテンツのパラメータを意識的に使い分ける」

ということです。<form> を使うと、とにかく POST メソッド！という感覚でリクエストすることになってしまうのですが、その時に「リソースの特定（たとえば dataId）」も「表示オプションの指定（たとえば display_order）」も「更新動作のコンテンツ（たとえば contents）」もすべて POST パラメータに突っ込んで、POST のリクエストを発行してしまいがちですが、これはもう少し意識的になってもよさそうです。

<form method="POST" action="/hogehoge/some">
<input type="hidden" name="dataId" value="13"/>
<input type="hidden" name="display_order" value="1"/>
<input type="text" name="contents"/>
<input type="submit" value="GO"/>
</form>

たとえば、表示のみならば、

<form method="GET" action="/hogehoge/some/13?display_order=1">
<input type="submit" value="GO"/>
</form>

というかたちでの書き方があるかもしれません。「POST を GET にするメリットなんて...」と思われるかもしれませんが、実はこれがあるのです。

Ajax を使っていろいろやっていると、妙なことに気づきます。それは、XMLHttpResponse() の挙動が、POST と GET で違う、ということです。GET メソッドで発行した時には、リクエストがキャッシュされて、実際のリクエストが飛ばないことがあるのです。これは要するに、「GET メソッドは状態を変えないアクセスだから、結果をキャッシュしてもかまわない」という原理でライブラリが書かれている、ということです。逆に POST メソッドは一切キャッシュされません。つまり、「状態を変更するのならば、POST でないと正しく動かないことがありうる」というのが、Ajax の前提なのですね。

同様の動作をプロキシがする可能性もあります。普通は POST メソッドでのリクエストを主体に Web アプリは書かれますから、「常にキャッシュなし」で動くことになります。このモデルは「何か操作をして、その結果を見て」の連続で動作する Web アプリの操作と相性がいいのですが、「見られる専用の部分」を GET メソッドで取得するようにすれば、キャッシュによってパフォーマンスが改善される可能性があります。

また、これは特に Ajax を副次的な機能として使う場合に重要ですが、「この操作の流れの中でデフォルトなパラメータ」と「一時的に何かをさせるために与えられたパラメータ」を積極的に区別すれば、「完全な表示状態」をクエリ文字列から取得できることになります。Ajax で副作用のある処理をさせた後に、表示の更新をかけたいのならば、単に「自分が呼ばれたURI」をそのままキックすれば、Ajax による副次的な更新結果を反映した表示を得ることができるようになります。リクエストパラメータの再構築とか、そういうややこしい処理は一切なしで、単に環境変数から QUERY_STRING を取得してそのままリクエストすればいいだけなのです。<form> を入れ子にできない制限から、副次的なフォームをメインのフォームの外に追い出して、JavaScript でパラメータをセットして叩く、というような可読性の低い処理とはおさらばしたいですよね！

というわけで、Servlet では「メソッドの種類を問わないように抽象化するので、そのパラメータがクエリ文字列出身なのか、リクエストのコンテンツ出身なのかは気にしない...」というのが当り前になった後で、これを再度区別するメリットが出てきているように思います。