実は、Ajaxのウラにこそ勝算がある：Web 2.0で変わるWebプログラミングの常識（1/5 ページ）

見た目にインパクトが大きいAjax利用のWebアプリケーション。しかし、その見た目を支える要となるものは、背後にある有益な情報処理と活用方法だ。Ajaxのインパクトに負けないWebアプリはどのように作られるのか？

[大澤文孝，ITmedia]

　このオンライン・ムックPlus「Web 2.0で変わるWebプログラミングの常識」では、これまでにAjaxの概要（第1回）から発展系としてどのような取り組みあるのか（第2回）、そして、効率的な組み込み方法の一つとしてJSONと呼ばれるデータ形式のやり取り（第3回）について解説した。

　この一連の特集を読むことで、プログラミングノウハウを一から十まですべてを学べるほどのボリュームは詰め込めないが、それでも最低限押さえておくべきポイントが理解できるはずだ。今回の記事でテーマとなるのは、Ajaxというものが見た目のインパクトさだけを表現するものではないということだ。

　Ajaxは、主にWebアプリケーションのフロントエンドとして用いられる技術。その背後は、サーバ上でOSやデータベースが支えている。文字や画像データを効果的に見せてこそ、Ajaxの技術が生かされるのだ。その発展系として考えられるWebサービス連携について説明しよう。

クロスドメインの制限はJSONと動的なscriptタグで解決

　第3回の最後には、クライアントからサーバへJSONで送信するやり取りを解説した（関連記事）。さて今度は逆に、XMLHttpRequestオブジェクトがXMLのデータを受信可能であるということを生かし、Webサービスとの連携を考えてみよう。

　近年Webサービスは、基幹を支えるものとして注視されており、Google API、Yahoo! API、Amazon APIなど、さまざまなWebサービスがAPIとして提供されている。Ajaxで、これらのAPIが呼び出せれば、さぞかし便利になるだろう。

　しかし残念ながら、XMLHttpRequestオブジェクトを使って、これらのAPIを呼び出すことはできない。これは技術的な理由ではなく、セキュリティ上からの理由だ。

　多くのWebブラウザは、XMLHttpRequestオブジェクトの通信先を、そのHTMLコンテンツを送信したのと同じサーバに限るよう、セキュリティの制限が課せられている。つまり、HTMLコンテンツと同じサーバにWebサービスが存在しなければ、該当するWebサービスを呼び出すことができないことを意味する。

　このような制限を「クロスドメインの制限」と呼ぶ。

プロキシで解決する

　この問題を解決する方法の1つが、サーバ側にもWebアプリケーションを配置し、通信をプロキシするというものだ（図1）。

図1■Webサービスの呼び出しを中継するプロキシ構造例

　プロキシによる通信手段では、データを加工するという選択肢と、データを加工しないという選択肢がある。

　つまり、単純にリクエストを中継してWebサービスからの戻り値（XMLデータ）をそのまま返し、JavaScript側でパースするという方法だけではなく、Webサービスからの戻り値を加工して、JSON形式などに変換してから返す方法もあるのだ。

動的なscriptタグで解決する方法

　クロスドメインの制限を回避するために、今までには、もっぱらこのプロキシを用いる方法が採用されてきた。

　しかし近年では、もうひとつ違う方法が使われ始めている。それは、「scriptタグを動的に作る」という方法だ。

　scriptタグでは、次のようにとして外部のJavaScriptのファイルを読み込むことができる。

<script language="JavaScript"
  src="ソースのURL">
</script>

　この時、scriptタグのsrcに指定する場所にはクロスドメインの制限がないのだ。つまり、インターネット上のどのような場所からでもJavaScriptのコードを参照することができる。