REST/Ajaxアーキテクチャにおけるサーバロードとネットワークトラフィックの削減

私は、ソフトウェアを構築する際、基礎的なツールを効率的に活用したソリューションを見つけられた時はいつも嬉しく感じる。私達は既存の複雑なレイヤー上に更に複雑なレイヤーを構築する代わりに、ソフトウェアアーキテクチャスタックの中核で問題を解決する方法を探している。私は、これらがなぜRESTfulとPOJOプログラミングモデルのようなアーキテクチャスタイルデベロッパたちの心に響くのか、という理由になると思うのである。DeveloperWorks上にAjax/RESTアーキテクチャのためにネットワークトラフィックとサーバプロセスをどのように減らすのかに関する短い記事(source)があるが、ここで一番重要なのはより複雑なソリューションを推進する代わりにHTTP 304ステータスコードを効率的に使用する方法なのである。この記事はAjax/RESTアーキテクチャにおける挑戦のコンテキストを設定することから始められている。

HTTPの純然たる事実はその素晴らしい強みと中心的な弱みにあります。HTTPはステートレスのプロトコルです。HTTPサーバへのそれぞれのリクエストがべき等なのです。つまり同じリクエストがそれぞれのインボケーションにおいて同じ結果を返還すべきということです。べき等性はRESTの概念の中核であります。同じリクエスト－多分コーディングクライアント情報であろう－がそれがいつ作られたかに関わらず、同じデータを返還すべきということです。しか し”同じデータ”の意味を理解するのは思ったより微妙なものなのです。同じデータが作られた時、同じURIが常に同一のデータを返還しなければならないのです。結局はコンテンツが修正された時には静的なWebページが変更するかもしれないのです。べき等性の裏にある概念は、起こった変更はGETリクエストそれ自体に直接的に影響するべきではないということなのです。だからこれのような常に変化しているリソースを所有する事は賢明なアプローチなのです。

http://myserver.example.com/latest_data/

この"latest_data"を作り上げている問題は、単にこのデータがいつ、誰によって受け取られたかということ以外の何かに関わっているのです。サーバは完璧にRESTfulになり、また”すべてのステート”を反映することが可能なのです。

彼らが解決しようとしているこの問題は二つ折りのものなのである。連続的なリクエストに対するネットワークトラフィックとサーバプロセスを減少させるということである。そのサーバプロセスの問題に取り掛かる方法は予想可能なものである。つまりキャッシングである。RESTfulアーキテクチャの利点の中の一つは、キャッシュ可能という能力があることである。しかしそれはサーバプロセス問題のみを解決しする。もし何も変わらなくても、まだあなたは全てのリクエストのためにネットワーク上でデータのフルセットを送るのだ。そしてそれがHTTP 304ステータスコードが入ってくる部分なのである。

この正しいソリューションは使用されていませんが、”修正されていない”問題は実のところHTTPプロトコル内で正しく提示されています。私達がするべき事は、単にHTTP 304ステータスコードを返還することです。304のステータスをチェックし、もし見つけたらポールから送られた（不在の）データに基づいたクライアントアプリケーションステートを単に変更しない事がAjaxコードの責任なのです。

JavascriptがAjaxを呼ばせるものを含めて、いくつかのコードサンプルを提供するのには十分良かったのである。また304のレスポンスを正しく処理する例は下記のようになる。

var r = new XMLHttpRequest();
r.onreadystatechange=function() {
    if (r.readyState==4) {
        if (r.status==200) {  // "OK status"
            displayData(r.responseText);
        }
        else if (r.status==304) {
            // "Not Modified": No change to display
        }
        else {
            alertProblem(r);
        }
    }
}
r.open("GET",'http://myserver.example.com/latest_data/',true)
r.send(null);