■ gooホームのOAuthリクエスト実装
- 「goo Social Platform」にOAuthリクエスト機能を追加 - 「goo」の広報ブログ「gooの音」
- gooホームガジェットからOAuthが利用できるようになりました! - gooホーム Developer's Recipe
- http://developer.home.goo.ne.jp/document/OAuth%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88
- http://devlog.agektmr.com/ja/archives/624
gooホームがOpenSocial ContainerとしてOAuthリクエストを実装しました。
gooホーム上で動作するOpenSocial Gadgetが外部のOAuth対応APIを利用できるようになったということです。
それと同時に、twitterのOAuth APIを利用したガジェツイ!が紹介されました。
OAuth対応APIでいま最も勢いがあると言ってもおかしくないtwitter APIを使ったこのGadgetを見て、OpenSocial Gadgetの新たな可能性を感じた方は多いのではないでしょうか。
ここからは私の個人的な考えです。
見過ごすことができない一言が書いてあります。
せっかくOpenSocial上に作ったTwitterクライアントということで、ならではのソーシャル機能を準備していたのですが、残念ながら今回の発表には間に合いませんでした(実装でき次第公開します)。
http://devlog.agektmr.com/ja/archives/624
twitterってのは「人のつながり」「アクティビティストリーム(がサービスそのもの)」という点で、がSocialなサービスです。
そのため、単純にGadgetに組み込んだだけでSocialなGadgetが出来上がった感覚が持てますが、新鮮さはあるもののそれだけでは「今までなかった形式のtwitterクローン」に過ぎません。
OpenSocial GadgetからOAuth対応APIを利用することの本当のメリットとは「Container上のSocialGraphを利用できる」ことです。
今日は少し、その辺に注目して考えてみます。
■ ポイントは『SocialGraph + 外部サービスAPI」が作り出す新たな魅力』
Socialなサービスを作るためには最低でも以下のような要素が必要だと思っています(他にも細かいのがあるとは思いますが)。
- Social Graph : ユーザー同士のつながり
- Activity Stream APIなど、Graphを利用する機能
- サービス本体
OpenSocialでは、上の2つはOpenSocial Containerが提供してくれます。
あたり前の話なのかもしれませんが、Gadgetを作る際に考えるべきこととはシンプルで、「どのようなサービスをソーシャルグラフと組み合わせるか」です。
OAuth対応APIによる外部サービス利用によって、以下の効果が得られると思います。
- 対1ユーザーのWebサービスを再活用
- 各サービス間のSocialGraphをマージすることによるソーシャルサービスの活性化
まずは、1ユーザーに対するサービスから取得したデータを適切な方法でContainer上のつながりの範囲で利用していくことで、新たなサービスが生まれます。
notSocialなサービスを提供しているみなさん、OAuth対応APIを使って新たなサービス展開を考えてみませんか?
gadget開発者のみなさん、今までだれも注目していなかったnot SocialなサービスをOpenSocialに取り込むことで、新たな魅力を引き出してみませんか?
もちろん、既にSocialなサービスをさらにマッシュアップすることもできるとは思うのですが、煩雑にならずにお互いのグラフマージのようなことをして拡張していくのはテクニックを必要とするような気がします。
ガジェツイ!を作られたgooの方も、この辺は考えられていると思いますので、今後の展開は非常に楽しみです。
また、OAuth利用に関しても、「SocialGpaphはContainerによってがらりと"色"が変わるため、同じGadgetでもいろいろなContainerで動かすことで使われ方が変わる」というGadgetの特徴は今までと同じなので、今後mixiなどが対応していくとどのような効果が出てくるか楽しみです。
■ (余談)もろもろ考えるとtwitterってすごい
ここまでで、『SocialGraph + 外部サービスAPI」が作り出す新たな魅力』についての個人的な考えを説明しましたが、
twitter APIの利用が活発になっている現状を見ると、この考えは、すでに開発者の頭の中には浸透していると思っています。
twitter APIを用いたマッシュアップサービスの場合、以下のようになっています。
- Social Graph : twitterが持つユーザーの関係。しかも、双方向の関係だけではない。
- Activity Stream : そのものがtwitterサービス
- サービス本体 : twitter APIを使う側の実装。位置情報と組み合わせたり、コミュニティ作ったり・・・
「何かの外部サービスを利用するOpenSocial Gadgetを作ろう」というモチベーションと、「twitteer APIを使って何か作ろう」というモチベーションは似ている気がします。
twitter上で「twitterはPlatformだ」という声もたまに聞かれますが、まさしくその通りだと思います。
twitterで何かしてやろうと思った/したことのある開発者は、どんどんOpenSocial Gadgetを作ってみることをお勧めします。