前回のエントリで触れたJSONP。初出はRemote JSON - JSONPというMochiKitの中の人によるエントリ(多分。一言で言うなら「JSONデータを括弧でくくった上でこっちが指定した文字列を頭につけて返してね?」というもの。文章で説明するとわけわからん。
つまり、
http://example.com/data.json?jsonp=beverly_hills
とリクエストしたら、
beverly_hills({
foo: 'This is foo.',
bar: 'This is bar.',
foobar: 'This is foobar.'
});
と返す。また、
http://example.com/data.json?jsonp=beverly_hills%5B90210%5D
とリクエストしたら、
beverly_hills[90210]({
foo: 'This is foo.',
bar: 'This is bar.',
foobar: 'This is foobar.'
});
と返すってこと。クライアント側は前回のエントリで触れたjsr_class.jsなんかを使って上記URLにリクエストしてやれば良い。JSONScriptRequestと触れる順序が逆だったことに今さら思った。
動的に作成したscript
要素によるJSONデータの読み込みというアプローチにはもってこいであることは言うまでもない。サーバー側でcallback関数名が決め打ちな場合とは違って、多重リクエストもやりやすい。前回のエントリの場合はまさにその「決め打ちな場合」であったので、JSONデータの読み込みは順番に処理してやるしかない(僕のアサマシツールみたいな小さなアプリケーションなら決め打ちでもあまり困らないけど)が、アウトプットするためのデータやUIを構築するためのデータやらいろいろ一気に必要になるという十分考えられるケースの場合、JSONP poweredであればあまりややこしく考えずにシンプルにアプローチすることが出来るはず。
そもそも動的に作成したscript
要素によるJSONデータの読み込みは結構前からある。それに対してクロス・ブラウザの実現や利便性などを追求した結果、サーバー側(データ提供側)の少しの労力でクライアント側に高い利便性(とてもべんり)を与えることの出来るJSONPを思いつくに至ったのだと思う。ような? JSONScriptRequestと触れる順序が逆だったとか上で書いたけど、この順序で良かった気がする。
クロス・ドメイン間でのデータのやり取りをJavaScriptコードの実行という形で行うことによるセキュリティの問題については割愛。というかきちんと問題を明確に把握して無いから書けないとも言う。
そういえば僕もどこかのどなたかと同じくZIPコードと言われてパッと思いつくのが90210だけ。