Tender Surrender

ラベル OpenSocial の投稿を表示しています。すべての投稿を表示

2009年11月15日日曜日

「OpenSocialのアーキテクチャ」スライドを公開します

去る11月11日にリクルートメディアテクノロジーラボの「カフェ」でTokyo GTUG(Google Technology User Group) #4のイベントが開催されました。テーマはOpenSocialで、今回は「OpenSocialのアーキテクチャ」というテーマで講演させて頂きましたので、スライドを公開します。

OpenSocialのアーキテクチャ

View more documents from Eiji Kitamura.

2009年9月15日火曜日

OpenSocial Hackathon in 会津

9月18日に会津大学で行われる会津ITサマーフォーラムで講演することになりました。僕のセッションでは「OpenSocialのアーキテクチャ」というマニアックなネタをお話をさせて頂く予定です。また、せっかくの会津なのでMashup Awards5のキャラバンも兼ねて、翌19日にOpenSocial Hackathonも開催することになりました。 OpenSocial入門を執筆されたmixiの田中洋一郎さんやMTLの川崎有亮さんも参加されます。地元の方は滅多にない機会だと思いますので、ぜひご参加ください。詳細と参加フォームはこちら: OpenSocial Hackathon in 会津

2009年8月29日土曜日

Shindigのコミッターになりました

「ウェブはソーシャルであるべきだ」。これは今の会社に
入社した2005年くらいからずっと訴えてきたことです。ソーシャルグラフをプラットフォーム化することで実現できることがたくさんあります。まずはポータルサイト全体をソーシャル化することを目標にし、作り上げたのがgooホームでした。

将来の構想はその時点で既にあって、いずれはポータル外のサイトとも接続して、インターネット全体がソーシャルグラフで繋がることをイメージしていました。そんな時に登場したのがFacebookです。

Facebookがやろうとしていたことは、SNSの中にサービスを取り込むという、僕の考えとは真逆でしたが、結果的にやろうとしていたことは似たようなもので、先に実現されたことにくやしい思いをました。そしてOpenSocialが登場します。

OpenSocialは仕様を民主的に決めて行くオープンなスタイルでした。オープン性のメリットは計り知れません。2つ以上のシステムを繋ぐのに、仕様から作るよりも、既に決まり事があれば話が早いのは火を見るよりも明らかです。技術的工夫もさることながら、コミュニケーションコストは大幅に削減できます。

さらに、オープンな仕様であればそれを使ったプロダクトが生まれやすくもなります。OpenSocial周りでも既に、よういちろうさんのOpenSocial Development EnvironmentやOpenSocial Client Library、OAuth関連ライブラリ、そして僕の作ったOpenSocial Signed Request Libraryなど、様々なオープンソースプロダクトが生まれ、後発の生産性を上げています。

そんなOpenSocial関連プロダクトの中心となるのが、OpenSocialコンテナのリファレンス実装であるShindigです。

僕がOpenSocialの既存仕様を学ぶ上で紐解いたのものこのShindigでした。当時はまだ日本でほとんど手をつけている人がいなかったため、API Expertとして声をかけて頂いたのも、Shindigに関する情報をこのブログで公開していたためです。

その後実際にgooホームでディプロイするに辺り、様々なパッチを書き、Shindigの開発チーム提供してきました。(もちろん、OpenSocialの仕様自体にも口を出してきましたが。)そうこうしているうちに、1年半ほどが経過し・・・

このたび、Shindigのコミッターになりました。

PHP版ShindigのメインコミッターであるChris Chabot氏とは、PHP版の最初のコミット前から連絡を取り、昨年のGoogle IOでも直接お会いし、その後もメッセンジャーで話したりしてきましたが、そのChrisにShindigのコミッターに推薦して頂いたのです。

Apache Software Foundationでコミッターになるには、既存コミッターの投票が必要らしいのですが、これまでの貢献を認めてもらい、承認して頂きました。

PHP版Shindigは今や、全世界述べ5億人(!)が26以上のSNSで使っているといいます。にも関わらずフィードバックされていたパッチはそれほど多くなく、自分がやってきたことは貴重だったようです。

本来僕にとってOpenSocialというのは理想のSocialWebを実現するための道具に過ぎないのですが、少なくとも日本では実質的なデファクトであり、mixiやgooホームで使われているShindigというプロダクトは、その根幹を支えるものです。

今後はShindigのコミッターとしても、日本のSocialWebを作り上げ、支えて行ければと思います。

2009年8月19日水曜日

(たぶん)世界初！OAuthを使ったOpenSocial向けTwitterクライアント「ガジェツイ！」を公開しました

gooホームのOAuth機能公開に合わせ、TwitterのOAuthを使ったガジェット「ガジェツイ！」(英語名GadgeTweetr)をリリースしました。ガジェットながらに、そんじょそこらのTwitterクライアントよりもシンプルかつ高機能で使いやすいものに仕上がったと思いますのでご紹介します。

※ガジェツイ！のロゴフォントには「ついってる」を利用させて頂きました。

主な機能

OAuthログイン機能

タブ機能

返信元表示機能

検索機能

マルチアカウントに対応

OAuthログイン機能

OAuthに対応していますので、IDとパスワードを直接gooホームに入力する必要はありません。「ログイン」ボタンクリックで、twitter.comドメインの画面が開くので、ユーザーは安心してログインすることができます。

login_using_oauth

タブ機能

タブで様々な種類のステータスを並べて表示するタイプのTwitterクライアントです。Timeline、Mentions、Direct Message、Favoritesなど、一通りの表示に対応しています。

tabs

返信元表示機能

ステータスが返信の場合は「返信元」をクリックすることで会話を辿って行くことができます。

replies

検索機能

フリーワード検索にも対応しています。

マルチアカウントに対応

ガジェットはいくつでも追加でき、それぞれに違うアカウントを指定することができます。

その他の機能

3つのビュー

home、profile、canvasそれぞれのビューに対応しています。homeではTimelineとMentionsが、profileでは当該ユーザーのステータスが、canvasではTimeline、Mentions、Direct Message、Favoritesがそれぞれデフォルトで開きます。

自動リンク機能

外部URLはもちろん、@によるID指定、そして#によるハッシュタグの指定を検知してリンク化します。URLの場合が別ウィンドウを開きますが、@と#の場合は新しいタブを作ってステータス一覧を表示します。

ReTweet機能

気に入ったつぶやきはこのアイコンをクリックすることで、いわゆる「ReTweet」することができます。もちろん、コメントを追記することができます。

プロフィール表示機能

アイコンクリックでフォロワー数や投稿数などのプロフィール情報を表示することができます。

フォロー、アンフォロー機能

プロフィール表示からそのままフォローしたり、既にフォローしている場合はアンフォローすることができます。

まとめ

せっかくOpenSocial上に作ったTwitterクライアントということで、ならではのソーシャル機能を準備していたのですが、残念ながら今回の発表には間に合いませんでした(実装でき次第公開します)。

とはいえ、gooホームのOAuthを体験してもらうためだけに作り始めたにも関わらず、シンプルかつ高機能なものに仕上がりました。ぜひガジェツイ！をお試しください。

2009年8月14日金曜日

OpenSocial Signed Requestライブラリ(PHP)をベータ公開

OpenSocialのSigned Requestは、ガジェットからの外部通信リクエストに署名を付けることで、パラメータの内容が改ざんされていないかを検証可能にする仕組みです。一般に2-legged OAuthやSigned Request、OAuth Consumer Requestという名前はすべて同じ、これを表しています。

実装自体は全く難しくないものなのですが、お手軽なライブラリがあまり出回っていないようなので、作ってみました。まずはベータとして公開します。

特徴

Google CodeにあるOAuthのライブラリを利用しています。公開鍵はorkut、Google、Friendster、hi5、hyves、Netlog、そしてgooホームとmixiのものを同梱しています。

使い方

Google Codeからチェックアウトしてください。

svn checkout http://opensocial-signed-request-php-library.googlecode.com/svn/trunk/ opensocial-signed-request-php-library-read-only

中身はサンプルガジェット(SignedRequest.xml)とサンプルのサーバーサイド実装(example.php)、そしてライブラリです。

サンプルのサーバーサイド実装を見て頂くのが一番早いですが、使い方はシンプル。ガジェットのURLを引数にしてSignedRequestValidatorをnewし、validate_requestメソッドを呼ぶだけ。署名の検証に失敗した場合は、勝手に401を返します。署名の検証に成功した場合のコードは、その後に続けて書けばOKです。

参考

僕の知る限り、他の言語でSigned Requestを検証するコードやライブラリを公開されている方も何人かいらっしゃいます。

Google AppEngine Python版 Django上で動作するgaeoauth
Google AppEngine Python版で動作するコード
Apacheモジュールレベルで動作するmod_auth_opensocial

まとめ

ベータ公開ではありますが、動作上の問題はないと思います。ただ、そのままのコードではGoogleからのリクエストもmixiからのリクエストもガジェットURLが合えば通してしまうため、任意に指定できるようにした方がいいかなど、フィードバックをもらって判断したいところと感じています。

※ちなみに、oauth_body_hashには未対応です。

というわけで、ぜひお試しください。

2009年6月17日水曜日

ガジェットのレンダリング速度を向上するPreload

今回はOpenSocialでネット上にあまり情報のないPreloadについて、解説してみます。

ガジェットレンダリングの流れ

単純にRSSを表示するガジェットを例に説明します。あるコンテナSNS上でこのガジェットを表示する場合、下記のような手順を踏みます。

コンテナSNSのレンダリング

ガジェットサーバーがガジェットをレンダリング

ブラウザ上でガジェットのJavaScriptが初期化

外部サイトのRSSを取得するためのAjaxリクエストをガジェットサーバーに送信

ガジェットサーバーが外部サーバーにリクエストを送信(キャッシュがあればスキップ)

ガジェットサーバーはレスポンスをブラウザに戻す

ブラウザ上でガジェットのJavaScriptがレスポンス内容を元に記事一覧をレンダリング

ざっとこんな感じになります。

OpenSocialコンテナの動きを理解していない人には若干分かりづらいかもしれません。この辺りの記事を参考にしてください。

さて、この一連の動きを効率化することで、全体の体感レンダリング速度を速くする方法があります。それが今回ご紹介するPreloadです。

ガジェットのレンダリングを高速化するPreload

Preloadは文字通り、レンダリングに先立ってロードしておいてくれる機能です。使い方は簡単で、/Module/ModulePrefs/Preload@hrefに呼び出したいURLを記述します。これで、先ほどのレンダリングの挙動が下記のように変わります。

コンテナSNSのレンダリング

ガジェットサーバーがPreloadで指定された外部サーバーにリクエストを送信(キャッシュがあればスキップ)

ガジェットサーバーがガジェットをレンダリング

ブラウザ上でガジェットがJavaScriptを初期化

外部サイトのRSSを取得するためのAjaxリクエストをブラウザ上で処理

ブラウザ上でガジェットのJavaScriptがレスポンス内容を元に記事一覧をレンダリング

図にしてみると一目瞭然ですが、通信部分のオーバーヘッドを削減できています。こりゃ便利。

仕組みは単純で、ガジェットがプリフェッチした外部コンテンツを埋め込んだソースコードをブラウザに渡し、makeRequest時にプリフェッチした内容が存在すれば実際のAjaxリクエストを行わずに応答を返してしまう、というものです。

Preload利用時の注意点

Preloadはとても便利な反面、扱いにくい性質のものでもあります。以下を理解して、ポイントを絞って使う必要があります。

キャッシュの有効期限をコントロールできない

結構致命的なのがこれです。キャッシュの有効期限をコントロールできないと、デフォルト(24時間が多い)のキャッシュ期限が適用されます。これを回避できるケースとしては、ユーザーが任意の動作でmakeRequestを行うため、その時にキャッシュの有効期限をクリアできる場合が挙げられます。逆に言うと、RSSを表示するだけでユーザーは任意に更新できない、でも更新頻度は1時間程度、というようなガジェットには向いていません。

ContentTypeを指定できない

通常makeRequestを行う場合、ContentTypeをDOM, FEED, JSON, TEXTから選択することが出来ます。特にFEEDに関しては、RSS/RDF/Atomを丸めてJsonで返してくれるため、慣れた人には便利な形式です,

しかしこの挙動は、明示的にContentTypeとしてFEEDを指定し、ガジェットサーバーが外部コンテンツを取得した際に特別な処理を行うことで実現されているため、ContentTypeを指定できないPreloadでは、これを行うことはできません。RSS等をPreloadしたい場合は、DOMを選択してパースするしかありません。

UserPrefsの内容を反映することが出来る

/Module/ModulePrefs/Preload@hrefの内容に__UP_****__といった形でUserPrefsの内容を含めることができます。これは残念ながらmixiアプリでは使えない技ですね。

[sourcecode language="javascript"][/sourcecode]

Signed Requestが使える

/Module/ModulePrefs/Preload@authzに"signed"を指定することで、署名リクエストが行えます。これの利点は、ガジェット側でビューアーのIDを指定しなくても、サーバーが署名と一緒に送ってくれるため、上記のUserPrefsのケースのように、URLを工夫する必要がない点です。

コードを変える必要はない

PreloadはガジェットXMLにメタデータを追加するだけですので、基本的にJavaScriptのコードをいじる必要はありません。もちろん、キャッシュを気にしたりするといじった方がよい場合もありますけどね。

Preloadはいくつでも指定できる

実はPreloadはいくつでも指定できます。これまでに挙げた条件をクリアしているのであれば、思い切って使ってみましょう。

まとめ

今回は存在が地味なのであまり注目されていないけど、うまく使えば非常に便利なPreload機能を紹介しました。うまいこと使いこなして、一流OpenSocialerを目指しましょう。

2009年4月29日水曜日

OpenSocialのパーミッションモデル

最近「OpenSocialでOwnner毎 or Owner*アプリ毎の永続化方法オプション」辺りでOpenSocialのパーミッションに関する疑問がいくつか挙っていたので、どういう場合にどのデータにアクセスできるのか、ついでに、FriendConnectにおけるパーミッションモデルについてもまとめてみます。

まずは最低限の知識としてビューアー(VIEWER)/オーナー(OWNER)という考え方と、基本情報/個人情報を押さえておきましょう。

ビューアーとオーナー

ガジェットは貼られる場所によって呼び方が異なり、これをビュー(view)と呼びます。OpenSocialでは標準的にhomeビュー、profileビュー、canvasビューが用意されています。ここを参考にしてください。

ご覧いただくと分かると思いますが、homeビューのガジェットは自分が見るマイページに貼られる前提で，profileビューは他人が見るプロフィールページに貼られる前提になっています。では，「自分が見る」「他人が見る」は何を意味するのでしょう？

OpenSocialガジェットには所有者/オーナー(OWNER)という考え方があります。オーナーとは，ガジェットをページに貼付けたページの持ち主を指しています。反対に，ガジェットを見る人を閲覧者/ビューアー(VIEWER)と呼びます。

つまり，homeビューで「自分が見る」が意味するのは，オーナーでありビューアー。逆に，profileビューで「他人が見る」が意味するのは，ページを見ているビューアーと，ページの持ち主のオーナーです。もちろん，プロフィールページをオーナー自身が見ているケースでは，オーナーとビューアーは同一人物になります。canvasビューでも同様。

基本情報と個人情報

OpenSocialではプロフィール情報は大きく2つに分けられます。
goo Social Platformではこれを基本情報(id, profileUrl, thumbnailUrl, nickname)と個人情報(その他のプロフィール)と分けて呼んでいます。詳細はこちらをご覧いただいた方が早いと思います。

基本情報は、必要最低限の情報で、個人情報はさらに詳細で重要性の高いものと思ってください。

基本ルール

これらを踏まえて、各種情報をやり取りする際に必要となるのが下記の基本ルールになります。

個人情報を取得する場合、対象となるユーザー(オブジェクト)が同じガジェットをインストールしていること

オブジェクトが友達の場合、ガジェットをインストールしていなくても基本情報のみ取得可能

更新・削除はビューアーが自分のデータを操作する場合のみ可能

ミソは、

友達でもガジェットをインストールしていない人の個人情報は取得できない

友達じゃなくてもガジェットをインストールしていれば個人情報が取得できる

ところ。

「なぜそんなに面倒なの？」「なんでガジェットインストールしてないと個人情報取れないの？」と思われる方も多いかと思いますが、理由はずばり、「プライバシーの保護」です。

個人情報はコンテナがユーザーから取得したものである

個人情報保護法では、収集した個人情報を事前に通告した目的外に利用してはならない

個人情報はコンテナが取得したものであり、第三者に譲渡や開示する(ディベロッパーがガジェット上で利用する)場合はユーザーがそれを理解している必要である

ユーザーは誰が自分の個人情報を取得したかを把握できる必要がある

ディベロッパーは受け取った個人情報を外部に流出させることも、売り渡すことも、理論的には可能である

ネット上にパブリックになっている情報でも、受動的に(スクレイピング等)渡す場合と、能動的に(API経由)渡す場合では、法的意味が異なる(そういう意味では、mixiのようなクローズなSNSでも、gooホームのようなオープンなSNSでも扱いは変わらない)

ディベロッパーが故意または事故で個人情報を漏らす等した場合、責任はもちろんディベロッパー側にあるが、情報を提供したコンテナは、ディベロッパーとの連絡を確実に取れる手段を用意しておく必要がある

若干複雑ですが、こんな理由で、本人が意図して利用していないガジェットに対しては、基本的に個人情報を渡さない方向に倒されている、という訳です。これはgooホームだけの話ではなく、まだ明示されてはいませんが、mixiも含め、今後登場するであろうOpenSocialコンテナすべてで似たような実装になると思います。

なお、基本ルールに対する特別ルールについては複雑になるのでここでは説明しません。興味のある方はこちらをご覧下さい。

FriendConnectのパーミッションモデル

さて、ここまで一般的なOpenSocialについて解説してきた訳ですが、FriendConnectにおけるガジェットのパーミッションについてここで考えてみましょう。

通常のSNS上のOpenSocialでは、ガジェットをインストールしているかどうかで個人情報を提供するか否かを決定していましたが、FriendConnectではちょっと事情が違います。それは、ガジェットのオーナーが人間ではなく、サイトである、という考え方に基づいている、という点です。

こちらの記事をご覧いただければ分かると思いますが、

Ownerはサイト。そういえば、FriendConnectガジェットを入れた時点では、自動的に自分がメンバーになったりはしていませんでした。Ownerは貼付けたサイトという仮想人格が担うようです。

サイトという仮想人格、というところがミソです。つまり、FriendConnectでは、ユーザーがオーナーになることはあり得ないのです。そのため、先に解説した一般的OpenSocialのパーミッションモデルをそのまま適用することはできません。

では、FriendConnectではどういう場合に個人情報を取得できるのでしょうか？

現実的には、私の把握している限り、まだFriendConnect上で基本情報以上の情報(個人情報)を取得することはできないので、必ずしも正しいとは言えないのですが、「そのサイトに参加しているか否か」がパーミッションを得るための条件のようです。

言い換えると FriendConnectの基本ルール：

個人情報を取得する場合、対象となるユーザー(オブジェクト)がガジェットを動かそうとしているサイトに登録していること

オブジェクトが同じサイトに登録していれば、個人情報も含め取得可能(実際は取得できないので想像)

更新・削除はビューアーが自分のデータを操作する場合のみ可能

となります。一般的OpenSocialの基本ルールと並べて比べてみると、違いが分かると思います。

まとめ

今回は、先日のHackathonでも多数の質問が出たパーミッションモデルの話を解説してみました。開発者にとっては面倒なだけですが、コンテナやユーザーにとっては、プライバシーを守るためにとても重要なことです。

OpenSocialガジェット開発もある程度のレベルに達してきたら、この辺りの理解をしっかりやっておくことが重要だと思います。

2009年4月1日水曜日

OpenSocial Hackathon開催します

gooホームサンドボックス立ち上げと丁度タイミングが合ったこともあり、gooとOpenSocial Japanコミュニティ、リクルートメディアテクノロジーラボ共同開催で、OpenSocial Hackathonを開催することになりました。

Hackathon(ハッカソン)とは、Hack(ハック)とMarathon(マラソン)を組み合わせた造語で、参加者をグループに分け、その場で実際にコーディングを行いながらソフトウェアを作りあげていくものです。

これまでにもGoogleを中心に数回開催されていましたが、今回はgooホームサンドボックスをコンテナにしてやってみようというものです。

主催： gooホーム、リクルート　メディアテクノロジーラボ、OpenSocial-Japanコミュニティ
日時： 2009年4月24日（金） 10:00〜18:00　（開場：09:30）
場所： リクルート　メディアテクノロジーラボ
人数： 35名
条件：

OpenSocialに興味がある方

JavaScriptでのプログラミング経験がある方

OpenSocialガジェットの開発経験のある方
(下記チュートリアルを行うとスムーズに理解することができます)
http://code.google.com/intl/ja/apis/opensocial/articles/tutorial/tutorial-0.8.html

ノートパソコンの持参が可能な方

※ 参加者の方は4月14日に事前ミーティングも行いますので、ご参加ください。
日時： 2009年4月14日（火） 18:30〜20:30　（開場：18:00）
場所： リクルート　メディアテクノロジーラボ
内容： Hackathonでのチーム分け等の手続き、アイディアの意見交換

参加をご希望の方は、下記2つのサイトにて登録を行ってください。

http://atnd.org/events/472

http://groups.google.com/group/opensocial-hackathon-0424
↑こちらに記載してある詳細をよくお読みください。

当日はOpenSocial入門を執筆されたよういちろうさん、川崎有亮さん、Googleの方、そしてもちろん僕もチューターとして参加します。

OpenSocialに興味がおありの方は、ぜひご参加ください！

2009年3月29日日曜日

gooホームサンドボックス公開

3月26日、gooホームでOpenSocial対応に向けたサンドボックス環境を提供開始しました。

主な機能は下記の通り：

基本的API(People、AppData、Activity)

homeビュー、canvasビュー、profileビューに対応

ユーザー属性情報ごとのプライバシー対応

requestCreateActivity、requestPermission、requestSendMessage、requestShareApp等の口コミ機能をすべて網羅

gooホーム絵文字フィーチャー

opensocial-jqueryフィーチャー

日本語であることはもちろんですが、仕様のカバー率という意味では、初めてOpenSocialに触れる方にとって、既存のどのコンテナより理想的な環境と自負しております。

また、ドキュメントはかなり力を入れて書きました。パーミッション周り等はなかなかちゃんと書いてあるドキュメントがないため、参考になると思います。ぜひご一読ください。

goo Developer's Kitchenディベロッパードキュメント

サンドボックスへの登録はこちらから

goo Developer's Kitchen

2009年2月6日金曜日

OpenSocialパネルディスカッション

来る2月12日、13日に目黒雅叙園にてDeveloper Summit 2009が開催されます。

中でも、12日17:40からOpenSocialパネルディスカッション 2009年、OpenSocial普及元年に「これから」を大予言にご注目。

最近「OpenSocial入門」を執筆された田中洋一郎さん、リクルートの川崎有亮さん、mixiから小山浩之さん、Googleの石原直樹さん、白石俊平さん、矢野りんさんに加え、僕もパネラーとして登壇することになりました。

今年はいよいよmixiやgoo、OpenPNEなど、日本でも複数のOpenSocial環境が利用できるようになるいわば元年です。OpenSocialが今後ウェブにとってどういう役割を果たして行くのか議論する予定です。ご興味のある方はぜひ、ご参加ください。

参加の申し込みはこちらから。

2009年2月3日火曜日

OpenSocialガジェット開発で注意すべきキャッシュ機能

先日の記事でShindigが持つOpenSocialアーキテクチャの強力なキャッシュ機能について触れました。Shindigには大きく4種類のキャッシュが存在しています。

ガジェットXMLのキャッシュ

makeRequestでアクセスされる外部APIのキャッシュ

featureを固めたJavaScriptのキャッシュ

JavaScript、CSS、imgなどHTMLからリンクされたリソースのキャッシュ

ガジェットXMLのキャッシュ

OpenSocialガジェットを開発し始めて最初につまずくのがこのガジェットXMLのキャッシュでしょう。ガジェットXML上で変更を行っても、それが実際のガジェット表示上に反映されない場合は、まずガジェットXMLがキャッシュされていることを疑いましょう。

ガジェットXML上でJavaScriptコードを修正しつつサンドボックス環境で動作確認しながら開発したい場合は、URLのquery部分にnocache=1を加えることで、キャッシュが無効化されます。これで開発がだいぶ楽になるはずです。(コンテナによってはURLの末尾が途中からhash(#以降)になっている場合があるので、気をつけてください。)

なお、iGoogleのサンドボックスではMy Gadgetsでキャッシュを無効にできたり、hi5ではサンドボックスなら特に何もしなくてもキャッシュが無効だったりといった特徴もあります。

makeRequestでアクセスされる外部APIのキャッシュ

makeRequestを使って外部のリソースにGETでアクセスした場合、これもキャッシュされます。例えばRSSを取得するような場合、更新頻度の低いものであれば相手方サーバーの負荷を少しでも軽減することができます。

これを回避したい場合は、makeRequestのopt_paramsにgadgets.io.ProxyUrlRequestParamters.REFRESH_INTERVALというパラメータを追加し、0に設定してください。これで、キャッシュされなくなります。

featureを固めたJavaScriptのキャッシュ

OpenSocialでは、ガジェットXMLにRequire@featureを加えることで、様々な機能が利用できるという仕様があります。このfeatureは、ガジェット内に表示されるHTMLにJavaScriptを追加することで機能を実現していますが、Shindigではここでも軽量化/効率化を図っています。featureのJavaScriptは、レンダリング時に難読化した上で全てをひとつに繋げて、キャッシュされます。

一般ユーザー/ガジェットディベロッパーがこれを意識する必要はほぼありませんが、頭の片隅にいれておきましょう。

JavaScript、CSS、imgなどHTMLからリンクされたリソースのキャッシュ

コンテナによっては(orkut, iGoogle, hi5等、今のところJava版のShindigを使っているサービス)、ガジェットXML内で指定された外部のJavaScript、CSS、imgが、レンダリング時にキャッシュされます。レンダリングされたガジェットのHTMLを見ると、キャッシュされた外部リソースのURLのpath部分の最後にconcatが付いていることから、キャッシュされていることが分かると思います。

この機能はContent Rewriteと呼ばれるのですが、OpenSocialバージョン0.9からは正式な機能として取り込まれますが、現段階ではShindig Java版独自の機能です。0.9では、ガジェットXMLの設定でどのファイルタイプをリライトするのか、JavaScriptなら圧縮するか、キャッシュする場合の有効期限はどれくらいか、などを指定できるようになります。

さて、このキャッシュは実運用時に各ファイルの置かれているサーバーの負荷を軽くすることが目的ですが、開発時にはコードの修正が即座に反映されず、効率を下げてしまうこともあるでしょう。これを回避するには、下記をXMLに追加します。

[sourcecode language='xml']

[/sourcecode]

コンテナによってはサポートしない場合がありますので注意してください。

ところで、PHP版 Shindigの場合はこの機能がありません。つまり、もしガジェットが例えば、あなたのサーバーに用意したファイルを指しているとしたら、ガジェットのレンダリングの度にリクエストが発生するため、開発には便利な反面、本番環境で大量にアクセスが来た場合サーバーに負荷がかかってしまいます。これを回避するため、キャッシュ機能をうまく利用する、というテクニックもあります。

http://opensocial-container/gadgets/proxy?url=http://devlog.agektmr.com/image.gifのように、ドメインに"/gadgets/proxy?url="を付けて、意図的にShindigのプロキシを入れてしまいましょう。(concatと異なり、難読化や圧縮はされません。)

追記(2009/2/3)

上記に関して、コメント欄でmainyaさんから、getProxyUrlを使ったやり方を教えていただきました。

[sourcecode language='javascript']
var params = {'REFRESH_INTERVAL' : 3600*24*7};
var url = 'http://example.com/img/logo.jpg';
try{
url = gadgets.io.getProxyUrl(url, params);
}catch(e){}
[/sourcecode]

このやり方でURLを取得すれば、コンテナに依存しない方法でキャッシュを意図的に効かせた参照を行うことができるようになります。(MySpaceでは使えないのでtry/catchした方がよいそうです)

2009年1月12日月曜日

OpenSocial(Shindig)のサーバーアーキテクチャ

OpenSocialと関わるには

コンテナになる

ガジェットを開発する

RESTを使ったクライアントサービスを作る

といった選択肢が考えられますが、そのいずれを選択するにしても、アーキテクチャについて知っておくことはとても重要です。特にガジェットを開発するに当たっては、アーキテクチャを知っていることでより開発しやすい場面が多々あります。

そこで今回は、OpenSocialに対応するコンテナのほとんどで利用されているオープンソースのリファレンス実装、Shindigのアーキテクチャについて解説したいと思います。

ガジェットとSNSの関係

iGoogle(既にShindigが利用されている)ではどうやって第三者の作ったガジェットを表示しているかご存知でしたか？実は、別ドメイン(iGoogleならgmodules.com)上にレンダリングしたガジェットを、iframe内に表示しているのです。

理由は、同ドメイン上に第三者の書いたJavaScriptを置くことは、セキュリティ上危険だからです。詳しくは以前Cajaについて解説した記事がありますので、そちらをご覧ください。

OpenSocial Gadget Rendering

APIはどこにあるか

OpenSocialにはPeople, Group, Activity, Persistentの4つのソーシャルなAPIが用意されていますが、それぞれRESTfulによるJSON, XML, AtomPub形式と、RPCによるJSON形式が用意されています。ShindigのJavaScript APIでは、この中でもRPCによるJSON形式が使用されています。

先ほど2つのドメインについて説明しましたが、JavaScriptのAPIということはAjaxなので、当然同じドメインということで、エンドポイントはShindigのドメイン上に存在します。

OpenSocial Server Architecture

ガジェット表示の流れ

基本的な構造が分かったところで、実際にガジェットを表示するまでの流れを見てみましょう。

どのガジェットを表示するのか

ガジェットを表示するためには、まずガジェットを表示したいというユーザーの意思が必要です。これはiGoogleであれば、ガジェットディレクトリから好きなガジェットを選び、自分のページを表示する、というサービス側での作業によって行われます。表示したいガジェットが分かったところで、サービス側もガジェットを表示するためのiframeを表示する必要があるため、ガジェットに関する情報を収集します。これはShindigのmetadata APIを使って行われます。

metadataの取得

metadata APIのリクエストを取得したShindigは、キャッシュを参照します。キャッシュにガジェットの情報が残っていない場合は、サービスからのリクエストに基づいてガジェットXMLを取得し、解析します。

iframeのレンダリング

ガジェットに関する情報を取得したサービスは、ガジェットを表示するためiframeをレンダリングします。これにより、iframe内にガジェットを表示するためのリクエストがブラウザからShindigに投げられます。

基本的にガジェットXMLに記述されたContentsの内容はそのまま表示されますが：

指定されたガジェットのfeature(tabやminimessageなど、ガジェットが持つ機能セット)のJavaScriptがHTMLに追記される。

設定によってはJavaScript、CSS、画像などのあらゆる外部コンテンツがShindig上にキャッシュして呼び出される。

という点は覚えておいて損はないでしょう。

これでガジェットの表示は完了です。Firebugなどを使ってAPIを試してみれば、Shindigにリクエストが飛んでいることが分かると思います。

外部サーバーを使うAPI

外部サーバーを使う際、JavaScript APIとしてgadgets.io.makeRequestが使用されます。コンテンツタイプとしてFEEDを選択すると、RSSやRDF、Atomを共通のフォーマットで返してくれたり、JSONを選択すると、データが返ってきた時点ですぐにJSONオブジェクトとして扱えるようになっています。

また、セキュリティ面でもいくつかの選択肢が用意されています。

通常のリクエスト

Signed Request

OAuth

通常のリクエストは、特に認証等のかかっていないAPIに対して行われるものです。Signed Requestとは、OAuth Consumer Requestを指しており、これを利用することで、外部サーバーはガジェットからのリクエストのみを扱うことができるようになります。OAuthはOAuth Coreを指しており、外部サーバーはガジェットからのリクエストであることだけでなく、誰からのリクエストなのかをセキュアなクレデンシャルで認証した上で扱うことができるようになります。

OAuthについてはこの辺りかこの辺りを参考にしてください。

ここで注意しなければならないのが、すべてShindigのproxyを介して行われるということです。先ほど書いた通り、ここでもGETリクエストには強力なキャッシュ機能が利用されるため、若干注意が必要な場合があります。キャッシュについては次回以降まとめて記事にしたいと思います。

2009年1月8日木曜日

Footprint gadget for your FriendConnect

I developed FriendIntroducer as an experiment and was trying to understand how FriendConnect is different from ordinaly OpenSocial implementation. So this time, I've tried to develop a gadget which you can find FriendConnect interesting, Footprints. You know the idea if you've tried MyBlogLog before.

What is Footprints?

Footprints is a gadget to track visitor of you blog. Look at the gadget on bottom left. If you're not joined or signed in, do it to check what it does.

Footprints1

As you could imagine, this gadget records visitor and its time. When viewed by others, timestamp will be displayed how long ago, you've visited. Also, you can remove your own footprint if you want. The xml is located at:

http://devlab.agektmr.com/OpenSocial/FriendConnect/Footprints.xml

http://gadgets.agektmr.com/Footprints/friendconnect.xml

Feel free to take it and use it on your blog.

2008年10月29日水曜日

米YahooがOpenSocialに対応

本日米Yahoo!から、Yahoo! Open Strategy 1.0として、ディベロッパ向けにYahoo! Application Platform (YAP), Yahoo! Social Platform (YSP), Yahoo! Query Language (YQL)がリリースされました。

Yahoo! Social Platform

プロフィールやアドレス帳、更新情報等、ソーシャルにまつわるAPIをRESTベースで提供するものです。認証機構にはOAuthを利用し、PHP版、Flash版のライブラリも提供されていますが、このREST APIはOpenSocial互換ではありません。

Yahoo! Query Language

SQLライクなコマンドを送信する事でYahoo! Pipesのようにデータ取得が可能なウェブベースのAPI。FacebookのFQLのようなもののようです。

Yahoo! Application Platform

Yahoo!上で動作する埋め込み型のアプリケーション。OpenSocialのガジェットプラットフォームは現時点ではサポートされていませんが、JavaScript APIは使えるようです。大きく2つのビューがあります。

Small View

HTMLまたはYML Liteのみサポート。JavaScriptはサポートされていません。YMLは、Facebookで言うところのFBMLのようなもので、 My!Yahoo等様々なページにパーツとして表示する事が想定されています。

Canvas View

ディベロッパが指定したURLが出力したYMLをプロキシして表示するタイプのアプリケーション。Facebookライクな仕組みですね。もちろん、サーバーサイドでYahoo! Social Platformを使ったプログラムを書く事で、OAuthで認証を行い、RESTベースでソーシャルグラフを取得したり、コンタクトリストを取得したりすることできます。

また、OpenSocial JavaScript API(v0.8)にも対応しているので、クライアントサイドから更新情報を追加するといった利用も可能な様子。Cajaが利用されているので、セキュリティに気遣う事なく実装できそうです。(いつのまに実用レベルに達していたのでしょうか・・・)

時間のある時にでもサンプルアプリケーションを作ってみたいと思います。

所感

今回のYahoo!のリリースは、FacebookプラットフォームとOpenSocialのいいとこ取りといった感じ。ただし、OpenSocialに完全に準拠している訳ではないので、他で作ったアプリケーションをちょっとだけ書き換えて転用、という訳には行かなそうです。

例えば、クライアントからmakeRequestを使って外部サーバーのデータを取得するようなJavaScript APIは利用する事ができません。また、OpenSocialならHTMLを出力すればよかったものが、YMLを出力しなければなりません。等々・・(追記：Gadgets Core APIは利用できるようです。ただし、Pref、Viewなど、featureで指定する機能は利用できません。また、YMLは通常のHTMLに加え、独自タグを使って拡張した機能が使える、というもののようです。ただ、Caja対応のために外部スクリプトを読み込めないことが、他のコンテナに実装したガジェットをインポートする際の障壁になりそうです。)

ただ、世界最大のポータルサイトがOpenSocialに対応することの意義は大きく、今後の動きは要注目です。全体の戦略からすれば、OpenSocialの対応はあくまでパーツに過ぎず、今後のウェブのあり方を位置づける重要な意味を持ちます。先日行われたYahoo! Open Hack Dayのプレゼンテーションは必見です。

どんどんプラットフォーム化していくウェブと、その中で占めるソーシャル機能の持つ重要性が、日本でも認識される日はそう遠くないと思います。

2008年10月20日月曜日

Orkutアプリのソースコードを覗くブックマークレット

OpenSocial-Japanのメーリングリストで出した小ネタを貼っておきます。

OpenSocialアプリ(ガジェット)はiframe内に表示されているのですが、iframeタグのsrc属性に含まれるURLのquery部分に、実はソースコードとなるXMLのURLが書いてあります。このブックマークレットを使えば、ワンクリックでソースコードを開くことができます。

Open Orkut Gadget XML

↑上記をブックマークレットとして保存し、Orkutアプリを表示した状態でクリックすると、ソースコードのページが新規ウィンドウで開きます。 (複数表示されている場合は、一番上のアプリのソースコードが開きます)

※Firefoxでしか動作確認してないので、動かなかったら教えてください。

2008年9月28日日曜日

OpenSocial v0.8.1が公開

OpenSocial v0.8.1仕様が公開されました。

OpenSocial Specification - Implementation Version 0.8.1(翻訳)

OpenSocial RESTful Protocol(翻訳)

OpenSocial RPC Protocol(未翻訳)

※翻訳については一部ベータ版からの修正内容が反映されていない箇所があります。誤りを見つけた際はご指摘ください。

リリースノートは下記の通り:

OpenSocialリリースノート

OpenSocialの仕様変更点

サーバーサイドAPIの変更 サーバー間通信機能に、よりシンプルなバッチ処理を可能とするJSON RPCプロトコルが追加されました。名前の一貫性を保つため、RESTful APIは今後RESTfulプロトコルと呼ばれます。

OpenSocial IDで許可する文字に"-", "_", "."を追加 OpenSocial IDは従来の英数字に加え、"-", "_", および"."を含むことができます。

Portable Contacts仕様にアライン

互換性のない変更点

RESTfulプロトコルの非互換性 RESTfulプロトコルから多くのクエリやレスポンスフィールドが名称変更/削除されました。RESTfulプロトコルの変更点全てを下記に示します。

RESTfulプロトコルの変更点

PortableContactsとの互換性 RESTfulプロトコルを実装することで、コンテナはPortableContacts仕様と技術的互換性を持つことになります。下記の変更点はこの互換性実現のために実装されました。

新しいレスポンス型format=xml リクエストがformat=xmlパラメータをサポートするようになりました。Peopleのリクエストはformat=xmlかformat=jsonで行われなければなりません。

コンテナはランダムアクセスなページングを実装しなければならない コンテナはstartIndexとitemsPerPageパラメータを使ったページングの実装が必須となりました。

コレクションのフィールドからrel=nextリンクが廃止 このパラメータはJSONコレクションレスポンスから削除されました

コレクションのフィールドからauthorが廃止 このパラメータはJSONコレクションレスポンスから削除されました

コンテナは全てのコンタクトを一度に返せなければならない コンテナは一度のリクエストで全てのコンタクトを返すことができなければなりませんが、パフォーマンス上の理由から返すコンタクトの数に上限を設けることができます。

itemsPerPageのデフォルト値 itemsPerPageパラメータがリクエストで指定されていない場合のデフォルト値はコンテナに依存します。

ソートパラメータの変更点 orderByパラメータはsortByに名称変更されました。また、sortOrderパラメータが追加され、ascending(昇順)とdescending(降順)を与えることができます。デフォルトはascendingです。

updatedSinceパラメータの追加 クエリで、指定された期間内に更新されたエントリのみを返すよう指定することができます。

ソートおよびフィルタリングが行われたかをレスポンスに表示ソートやフィルタリングはコンテナにとってコストが高いため、実際にリクエストと同じ内容のフィルタリングが行われたかを示す、トップレベルのレスポンスフィールドfiltered, sorted, updatedSinceがレスポンスに含まれるようになりました

削除されたPersonオブジェクトのリクエストが可能に 新しく追加された@deletedセレクタとupdatedSinceパラメータを利用することで、指定された日時以降に削除されたコンタクトの取得が可能になりました。

Personレスポンスは最低でもidとnameフィールドを含まなければならない コンテナはnameおよびidフィールドをPersonデータに含まなければなりません。

profile URLはURLでもなければならない PersonのprofileUrlフィールドで返される値はtypeがprofileのエントリのurlsフィールドでも返されなければなりません。

Personにphotosフィールド追加 Personにurl, type, primaryサブフィールドを持ったエントリのリストを含む、photosフィールドが追加されました。PersonオブジェクトでthumbnailUrlフィールドが返された場合、このurlはtypeがthumbnailであるエントリのphotosフィールドにも存在しなければなりません。

Personにimsフィールド追加 Personにvalue, type, primaryのサブフィールドを持ったimsフィールドが追加されました。type値としてよく使用される"aim", "gtalk", "icq", "xmpp", "msn", "skype", "qq", "yahoo"が定義されていますが、新しいtypeを定義することもできます。

Personにaccountsフィールド追加 Personにその人がアカウントを所有する他のサービスを表すaccountsフィールドが追加されました。このフィールドはdomain, userid, username, primaryサブフィールドを持ったエントリのリストを含みます。

Personの複数フィールドにprimaryサブフィールド追加 Personのemails, urls, ims, phoneNumbers, addresses, organizations, photosフィールドに、リスト中どのフィールドが主たるものか(存在する場合のみ)を示すprimaryサブフィールドが追加されました。

jobsおよびschoolsの複数フィールドをorganizationsに統合 jobsおよびschoolsのエントリはorganizationsという名前のOrganization構造の配列にまとめられました。Organization構造は"job"、"school"を正規値とするtypeサブフィールドで拡張されます。

Personの複数フィールドをvalueフィールドに標準化 Personの複数フィールドで主となるテキスト値はvalueというサブフィールドに保存されるべきです。これはemails.address, phoneNumbers.number, urls.addressおよびすべての{Enum}.keyフィールドのインスタンスを{Enum}.valueに名称変更することが必要となります。addresses, accounts, organizationsフィールドは複雑なため、valueフィールドのコンセプトが存在しません。ソートやフィルタリングを行うため、これらのフィールドの"主たる"サブフィールドに該当する部分は、addresses.formatted, accounts.domain, and organizations.nameとなります。

Person.genderフィールドは文字列に Personではgenderを文字列フィールドとして扱い、"male"および"female"を正規値とします。

AddressesからextendedAddressまたはpoBoxサブフィールドが廃止 streetAddressサブフィールドに完全な(複数行の場合もある)住所を保存することができるようになったため、AddressサブフィールドのextendedAddressおよびpoBoxが廃止されました。

unstructuredAddressをformattedに変更 AddressのunstructuredAddressサブフィールドはformattedに名称変更されました。

dateOfBirthをbirthdayに変更 PersonのdateOfBirthフィールドはbirthdayに名称変更されました。

timeZoneをutcOffsetに変更 PersonのtimeZoneフィールドはutcOffsetに名称変更されました。

nicknameの定義 Personのnicknameフィールドは"現実世界でこの人物を指すくだけた方法"と定義されました。

Personフィールドのデフォルトセット Personリクエストでクエリパラメータfieldsがない場合、JS APIのデフォルトと一致させるため、最小限必要とされるデフォルトセットとしてid, name, thumbnailUrlが定義されました。

supportedFieldsのクエリ RESTfulプロトコルにコンテナがサポートするPersonおよびActivityフィールドをリストで返す/people/@supportedFieldsおよび/activities/@supportedFieldsというエンドポイントが定義されました。

indexByの廃止 indexByクエリパラメータは廃止されました。

Activity.titleフィールドはHTML文字列に Activityタイトルフィールドは複雑なデータオブジェクトではなく、HTMLマークアップを含む文字列として扱われるようになります。

unstructuredをformattedに変更 名前フィールドのunstructuredはformattedに変更されました。

displayNameフィールドを追加 PersonフィールドのトップレベルフールドとしてdisplayNameが追加されました。

RPCプロトコルの変更点

RPCプロトコルが登場 バッチ処理や複雑なサーバー間処理を簡易化するためのオプションとして、新しくRPCプロトコルが登場しました。

opensocial.* JavaScriptの変更点

新しいopensocial.IdSpec.GroupId enum IdSpecオブジェクトを構成するため、opensocial.IdSpec.GroupId.FRIENDSまたはopensocial.IdSpec.GroupId.SELFを使用することができます。

supportsFieldのレスポンスを定義 opensocial.Environment.supportsField()の戻り値として、コンテナがフィールドをサポートする場合はtrue、そうでない場合はfalseを返すことが定義されました。

gadgets.* JavaScriptの変更点

gadgets.* JavaScript APIに変更点はありません。

Gadgets XMLの変更点

要素でOAuthをサポート 要素のauthz属性で"oauth"値がサポートされるようになりました。authzがoauthの場合、oauth_service_name, oauth_token_name, oauth_request_token, oauth_request_token_secret属性が取得されます。これらの属性はgadgets.io.makeRequestパラメータに一致するものと同様の意味とデフォルト値を持ちます。

2008年8月2日土曜日

OpenSocialのOAuthまとめ

OpenSocialでは、コンテナが外部サーバーとの通信を行う際、または外部サーバーがコンテナと通信を行う際、OAuthを使用して認可を行います。今回はOpenSocialにおけるOAuthについて、現段階でのまとめを書いてみます。 ※追記(2008/10/20)：2008/10/4に書いたコチラの記事も必読です。

OAuthって何だったっけ？

OAuthはユーザー、コンシューマ、サービスプロバイダの3者間でデータのやり取りを行うとした場合、ユーザーがコンシューマにクレデンシャル(IDやパスワード)を渡すことなく、ユーザーが所有するサービスプロバイダ上のリソースにコンシューマをアクセスさせるためのものです。例えばユーザーがGoogle(サービスプロバイダ)のアドレス帳(リソース)をMySpace(コンシューマ)上で利用するシーンを思い浮かべてください。OAuthがなければ、MySpaceにGoogleのIDとパスワードを預けなければならなかったものが、OAuthを使うことで、ユーザーが直接Googleと認証のやりとりを行い、MySpaceにGoogleのID/パスワードを渡すことなく、アドレス帳のデータをMySpaceに渡すことができるようになります。

2種類のOAuth

さて、そんな便利なOAuthですが、OpenSocialで利用されるものには2種類あります。

OAuth Core

OAuth Coreでは、先程説明したように、ユーザー、コンシューマ、サービスプロバイダの3者間でやり取りを行います。ベーシックなものですので、詳細についてはこの辺りを参考にしてください。

OAuth Consumer Request

一方OAuth Consumer Requestは、OAuthの仕様からユーザー認証部分を除き、コンシューマとサービスプロバイダのやり取りにフォーカスした仕様で、一般に"two-legged OAuth"と呼ばれます。これはコンシューマとサービスプロバイダの信頼関係だけで、ユーザーによる認証を伴わない仕様のため、コンシューマがサービスプロバイダからパブリックな情報を取得したい場合に利用するケースが想定されます。 (かなり恥ずかしい間違いです。正確にはコンシューマが署名を付加することで、サービスプロバイダがリクエスト元とリクエスト内容に間違いがないことを確認できる仕様、です。/ 2009年10月追記)ちなみにOpenSocial v0.7ではOAuth Coreの利用は仕様に含まれておらず、このtwo-legged OAuthを利用することになっています。OAuth Coreが利用できるのはOpenSocial v0.8以降での話になります(もちろん、two-legged OAuthも利用できます)。

OpenSocialにおけるOAuth利用パターン

OpenSocialでOAuthを利用する形態として、さらに2通りが考えられます。

ガジェットが外部サーバーとやり取りを行うOutbound OAuth

ここでは仮にOutbound OAuthと呼びます。type="html"で作られたガジェットが、SNSコンテナをプロキシとしてコンシューマの役割を果たし、サービスプロバイダとなる外部サーバーとmakeRequestで通信を行うケースです。

外部サーバーがコンテナとやり取りを行うInbound OAuth

ここでは仮にInbound OAuthと呼びます。コンシューマとなる外部サーバーがサービスプロバイダであるSNSコンテナのRESTful APIを叩くケースです。type="url"のガジェットが外部サーバーを通してSNSコンテナのRESTful APIを叩くケースもこれに該当します。

OAuthの利用に必要なもの

OAuthの利用には前提条件がいくつか存在します。細かい仕様は別途調べていただくとして、事前に必要な条件が下記になります。

コンシューマが、サービスプロバイダの発行する以下を事前に知っていること。
- コンシューマキー(consumer_key)
- コンシューマシークレット(consumer_secret)

コンシューマが、サービスプロバイダとOAuthのやり取りを行う以下3つのURLを知っていること
- サービスプロバイダのリクエストトークンURL
- サービスプロバイダのアクセストークンURL
- サービスプロバイダの認証URL

※追記(2008/10/20)：コンシューマシークレットについては、署名方式がRSA-SHA1の場合、必須ではありません。詳しくはコチラ。 OAuth利用パターンごとにどのようにしてこの条件をクリアするかを検証してみます。

Outbound OAuthのケース

ガジェットが外部サーバーとやり取りを行うケースですので、まずはガジェット開発者がSNSコンテナにコンシューマキーとコンシューマシークレットを登録します。ですが僕の知る限り、まだOutbound OAuthを実装しているSNSはありません。なので、ここでは何かしらの手段を用いて(SSLページでFormを使って投稿等)、コンシューマキーとコンシューマシークレットをコンテナに渡したものと想定してください。(今後順次、これを実現する方法は登場するものと思われます。) 次に、サービスプロバイダの各種URLを渡す必要がありますが、v0.8ではガジェットXMLで渡すよう規定されています。OAuthをModulePrefsの中に作成してください。

[sourcecode language='xml']

[/sourcecode]

OAuthは必ずしも1つのサーバーとやり取りするとは限りませんので、Serviceを追加することで複数をサポートすることができるようになっています。Service@nameで使い分けることが出来るようになっていますので、必要に応じてmakeRequestのopt_paramsに下記のパラメータを加え、サービスを指定してください。

gadgets.io.RequestParameters.OAUTH_SERVICE_NAME

サービスプロバイダとOAuthのやり取りを行うURLについては、XRDS-Simpleによって解決する方法もありますが、こちらについては別の機会にまとめてご紹介します。

Inbound OAuthのケース

外部アプリケーションがSNSコンテナのRESTful APIにアクセスする場合になります。これはまさに、FacebookのFacebook ConnectやMySpaceのData Availability、GoogleのFriendConnectに該当するもので、まだ実験的な段階にあると言えるものです。コンシューマキーとコンシューマシークレットですが、SNSコンテナ上でアプリケーションを登録することで発行されます。それをディベロッパがメモ/コピペしてコンシューマとなるサーバーのコードに埋め込みましょう。URLについては、単純にヘルプページを見る方法と、XRDS-Simpleによるオートディスカバリを行う方法が考えられます。

まとめ

今回は大まかな話を書きましたが、次回は実際にMySpaceのData Availabilityを使ってOAuth認証を行い、データを取得するところまでを試してみたいと思います。

2008年7月10日木曜日

OpenSocial API仕様(v0.8)を翻訳しました

OpenSocial API仕様(v0.8)

一ヶ月くらい前から出来てたのですが、一応ブログ記事にも書いておきます。何か間違い等ありましたらお知らせください。

2008年6月17日火曜日

OpenSocial RESTful API Specificationを翻訳しました

これまで公開していたOpenSocial RESTful API Proposalの翻訳を、OpenSocial v0.8仕様のリリースで公開されたOpenSocial RESTful API Specificationに置き換えました。

ただし部分更新処理の項目についてはTBD(To Be Determined)のままになっています。問い合わせしているので、最新版に更新され次第アップします。

2008年6月12日木曜日

OpenSocialのAtomPubはXRDS-Simpleでディスカバリ

OpenSocial v0.8のRESTful API仕様では、オートディスカバリにXRDS-Simpleを利用するよう規定されています。

他方、OpenSocial v0.8で利用されるRESTful APIはAtomPub形式となっており、AtomPubではService Documentを利用するよう規定されています。

これではコンテナサイトがどちらを使うのか、両方使うべきなのか疑問が残ってしまいます。この件について、Google GroupsのOpenSocialの仕様を検討するグループに質問を投げてみました。

質問

コンテナサイトはAtomPubのService DocumentとXRDS-Simple、どちらを採用すべきなのでしょうか？両方サポートすべきでしょうか？

David Primmer氏の回答

AtomPubのService DocumentはURLの一部をテンプレート的に定義して変数を当てはめる用途には向いていない。ある程度固定されたURL上で指定することを想定されているようだ。
その点、XRDS-Simpleは空白に値を埋める形でURLをディスカバリできる点で優れている。

この点に関しては、AtomPubのPerlライブラリを実装されたたけまるさんも指摘されていて、XRDS-Simpleを利用する方が合理的であるという点では一致しています。

ただ、仕様に適合しないという意味では気持ちの悪いものであることは間違いなく、この点をどこかで解決できないかと考えています。先ほど紹介したGoogle Groupsで「AtomPubの仕様作成者に仕様変更の提案を行う予定はあるか」との質問を投げたのですが、その後応答はありません。

現時点でRod Yatesという方からこちらの仕様書から適用できるのではないかとの提案を頂いているので、AtomPub識者の方と相談して何かしらの働きかけを行っていこうと思います。

登録: 投稿 (Atom)