Google Friend Connect API に gadgets.io.makeRequest 相当を自前で実装する

Google Friend Connect のOpenSocial APIには gadgets.io.makeRequest が含まれていない（今のところ）。もしあると個人的にちょっとだけ嬉しかったりするので、作った。これでHTML側ではGFCのスクリプトをロードするだけで、任意のサーバに対してHTTPリクエストを送ることができる。リソース側にJSONPインターフェースとかcrossdomain.xmlは必要ない、いわばGFCをオープンなクロスドメインプロキシとして使っている。

e.g.
http://gfcxd.googlecode.com/svn/trunk/xd-test.html

opensocial-jquery版。ちゃんと動く。

http://gfcxd.googlecode.com/svn/trunk/opensocial-jquery-test.html

ContentTypeがDOMの場合はRPCでJSONシリアライズができなさそうなので、たぶん動かない。単純にmakeRequestのコールバック結果をそのままRPCに渡してるのがいけないだけで、やろうとおもったっらページ側でXML parseしなおしてやればいいはずなので、これは単なるさぼり。

さっき見たけど、IEで動いてなかった。なんでかな。あとで調べる。

中身

作るにあたって、Google Friend Connect API のアーキテクチャを若干解析してみた。GFCのOpenSocial API呼び出し時にサーバへの通信がおこなわれるが、これはすべてガジェット経由のフレーム間RPCになっている。OpenSocial API通信のためのガジェットみたいなのが用意されていて（http://www.google.com/friendconnect/gadgets/osapi-0.8.xml）、これらがコンテナ側（GFCスクリプトをロードしたページ）と協調動作する。

ここで、実装の方針として、同じようにgadgets.io.makeRequestをプロキシしてやるようなガジェットを作ってやって、それ経由で呼び出してやればOKだろう、と考えた。

そこで、とりあえずやってみたのだが、ガジェット=>ページはできるけど、ページ=>ガジェットへの通信ができない。いろいろ調べて、Shinding実装のRPCの原理から考えて、双方向通信のためには、ページ側のRelay HTMLだけじゃなく、ガジェット側のRPC Relay HTMLがどこにあるか知ってないといけない、ということに気づく。

ただし、そもそもガジェットのURLはそれぞれ個別のドメインがわりあたえられるので、その場所をどうにかしてページ側で把握しておく必要がありそう。GFCのOpenSocial API呼び出しのガジェットの場合はどうやってるのかな、と思ってみてみたら、ドメインまで含めてスクリプト中にハードコードしてるようでした。なので、FriencConnectのコンテナはガジェットXMLに対して常に一定にドメインを割り振るのだろうと解釈し、こっちのガジェットも調べたURLをそのままハードコードしてる。

google.friendconnect.container.setDomainは、ガジェットのRPC Relay のベースURLを伝えるためのAPI。ドキュメントにはないので、おおっぴらに使うのは避けたいところ。

その他

YQLがある時代になにやってんの？という突っ込みはあまり期待していません。POSTができたりとか、将来的にOAuth Proxyできるかも、みたいなところがちょっといいかもね、とおもいます。