関数名固定のコールバックをJSONPと言うことについて

http://jsonp.yatena.com/

実際のJSONPデータをご覧頂ければわかりますが、callbackの関数名はkakaku_wsとなっております。

http://blog.livedoor.jp/dankogai/archives/50639200.html

送られてくるjsonpはこんな風になっています。

parse_yubin2jsonp('東京都','千代田区','千代田');

いや、そもそも現在主流のJSONPの解釈自体が提唱者の元々の定義からぶれているので、定義にこだわるつもりはあんまりない。

ただ、「xxxがJSONP対応したよ！」っていわれて、じゃあ試してみようと思ったら、自前のクライアントライブラリが使えなかったときというのがとても悲しい。自分でスクリプトタグをコードに書けばいいんだろうし、ページに結果を貼り付けるだけの小さな用途であればそれで十分なんだろうけどね。

でもこのスクリプトロードによるHack的な側面を隠蔽化して、できるだけJSONPã‚’Webサービス呼び出しっぽく扱うために各種ライブラリがあって、そこでは dojo にしろ prototype.js ã‚„ Mochikitの拡張にしろ、コールバック関数名をURLパラメータで与えることをある程度前提にしてるから、汎用性が出るわけです。

関数名固定型のJSONコールバックサービスは、こういったライブラリからは呼び出せない。せっかく再利用できる仕組みがあっても、そのサービスのために新たにコードを起こすことになる。つまりJSONPによるせっかくの標準化の恩恵を授かれない。

もちろん、関数名固定型のコールバックにも有利な点はある。それは、サービスの提供に必ずしも動的なコンテンツ生成エンジンを必要としない、ということ。RSSフィードのように、あらかじめファイルを生成しておいてあとはWebサーバに配置しておくだけ、というやり方でOKで、参照されるたびにコンテンツ生成のためのサーバリソースを費やすということはない。

だけど、もしキャッシュにそれほど意味がなく、paddingの処理時間の比率が無視できるような動的サービスだったなら、できるだけ関数名はパラメータとして受け取れるように実装してくれた方がうれしい。標準から外れてしまうことで利用の可能性が狭まっちゃうのはサービス側にとっても不本意だろうと思うし。

あ、リバースプロキシで高速にpadding部分を書き換えるキャッシュがあってもいいよな、と思った。新しいmod作るか？

（追記）
これは自らJSONPとはいってないけど、影響力でかいと思うので。いまさらJSONサービスでコールバックを固定にした意味がまったく分からない。

http://www.flickr.com/services/api/response.json.html

When a request is successful, the following JSON is returned:

jsonFlickrApi({...});

（追記２）
あれ、FlickrのJSON呼び出し、いつの間にかコールバック関数指定できるような説明書きになってる。覆面更新はひどいなあ。

http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=0a0c1ce385ca8869648ba1181ad3df80&tags=autostitch&format=json&jsoncallback=handleSearchResults

→テスト