Hatena::ブログ(Diary)

Yet Another Hackadelic

2011-02-13 心変わり

JSON-RPC, RESTful API とクエリパラメータ

OpenSocial の JSON-RPC, RESTful API の設計についてのよもやま話です。

JSON-RPC とクエリパラメータ

OpenSocial Core API Server Specification 1.1URL Addression と言うセクションがあります。

これは JSON-RPC を http GET で呼び出す際に params の部分など構造化されたデータをどうやって渡すのって際の仕様になります。

JSON Object URL Parameter
{ "field" : "value" } field=value
{ "field" : [1,2,3,4,5]} field=1,2,3,4,5
{ "field" : "12" } field='12'
{ "field" : [identifier,anotheridentifier]} field=identifier,anotheridentifier
{ "field" : ["value","another value"]} field=value,"another value"
{ "field" : ['value','another value']} field=value,'another value'
{ "field" : { "nested" : "value" }} field.nested=value
{ "field" : [{ "nested1" : "value1" }, { "nested2" : "value2" }]} field(0).nested1=value1&field(1).nested2=value2

まぁシングルクオートとダブルクオートを意図的に使い分けたいユースケースがさっぱり意味が分からない上に、identifier とか意味分かんないんでこの辺り謎過ぎるのですが、そういう細かい突っ込みはとりあえず置いておきます。

ところで JSON-RPC 2.0 の extension として定義されている JSON-RPC over HTTP によれば、GET の時の挙動は3.5 GET に書いてあり、params の部分はエンコードしろと書いてあります。どういう風にエンコードするかと言えば Base64 して URL Encode しろと言う感じです。

Pre-Encoded Params:
http://<end point>?method=sum&params={"a":3,"b":4}&id=2
http://<end point>?method=sum&params=[3,4]&id=1
Encoded Request:
http://<end point>?method=sum&params=eyJhIjozLCJiIjo0fQ%3D%3D&id=2
http://<end point>?method=sum&params=WzMsNF0%3D&id=1

って感じ。これはこれで単純明快ですね。

ちなみに先に JSON-RPC に対して結論を言っておくと、誰が楽しくて GET で叩くのか僕には意味が分かりません!*1大人しく POST 使いましょう。

RESTful API とクエリパラメータ

それでもやっぱり RESTful API が好き!と言う方も多いでしょう。僕もそうです。何度痛い目に合っても何故か好き。

まぁそんなことはどうでも良いのですが、OpenSocial RESTful API は中々面白い機能が幾つかあって、

  • Partial Update
  • Filter & Sort

辺りが挙げられます。Partial Update は冷静に考えると利便性の観点から出来て然るべきなんですが、ここでは触れない事にします。

Filter & Sort の辺りは Open Search 辺りからやってきた概念でしょう。

Filter や Sort なんですけど、例えばこんな風に書きます。

http://example.com/people/@me/@friends?filterBy=displayName&filterOp=startsWith&filterValue=zigo&sortBy=id&sortOrder=descending&count=50&startIndex=1

まぁ特に説明しなくても理解出来るとは思いますけど。

現時点の RESTful API の仕様では filter をもっと複雑に記述するなんて事は出来ません。と言うのも AND なのか OR なのかを指定する仕組みが無いからだと思うのですが、まぁ OR は要らないすよね。

そこで冒頭の JSON-RPC の URL Addressing から Syntax を借りてくると、こんな風に書けるかもしれません。

http://example.com/people/@me/@friends?filterBy(0)=displayName&filterOp(0)=startsWith&filterValue(0)=zigo,kaz,hid&filterBy(1)=gender&filterOp(1)=equals&filterValue(1)=male

この部分をデータ構造にすると、

{
  "filterBy": ["displayName", "gender"],
  "filterOp": ["startsWith", "equals"],
  "filterValue": [ ["zigo", "kaz", "hid"], "male" ]
}

みたいな感じとなり、SQL で表現すれば、

WHERE ( displayName LIKE 'zigo%' OR displayName LIKE 'kaz%' OR displayName LIKE 'hid%' ) AND gender = 'male';

のようになると。

実は某プラットフォームの API v2 ではこの記法が使えるらしいのですが、とりあえず undocument & no supports です。

雑感

とりあえず JSON-RPC に関して仮に GET をサポートするのであれば本家の方の仕様( Base64 )の方がすっきりしていて良いかなと思います。あと、一般論としてクエリパラメータとして何か構造化されたデータを埋め込む場合も、これと同様の手法の方が便利だろうなと思います。

RESTful API と filter の議論ですけど、こういうのもありかなとは思います。

*1:監視用途とかなら意味があるかもしれない

2010-02-23 壊れかけのレイディオ

URI::Template::Restrict 0.04

コラボレータに加えて貰って、0.04 をさっき id:ikasam_a に ShipIt して頂きました。そのうち cpan コマンド等でインストール出来ると思います。id:ikasam_a++

URI::Template::Restrict なんですが、extract() の処理が process() と同様の厳格なルールになっていて、実際に使う際にちょっと困ってました。

例えば、OpenSocial の RESTful API でありがちそうな以下のような URI Template に対して実際の URI をぶつける例、

#!/usr/bin/perl

use strict;
use warnings;

use Data::Dump qw(dump);
use URI::Template::Restrict;

my $t = URI::Template::Restrict->new(
    'http://example.com/api/people/{guid}/{selector}{-prefix|/|personId}'
);

my %uri_params = $t->extract(
    'http://example.com/api/people/@me/@friends/100'
);

print dump(\%uri_params);

これはまったく何もマッチしないんですよね。これは "@" が URI Template 的には vardefault って部分なんですが、この部分の process 時のルールが percent encoding または unreserved って決まってるのでこうなってる。面倒ですね。

と言う訳で extract の時だけルールを緩和して、期待通り、

{ guid => "\@me", personId => 100, selector => "\@friends" }

って感じで取れるようにしたのが 0.04 になります。

ちなみにモバゲーオープンプラットフォームの Avatar API って奴だと、まぁこんな感じの URI Template になります。

#!/usr/bin/perl

use strict;
use warnings;

use Data::Dump qw(dump);
use URI::Template::Restrict;

my $t = URI::Template::Restrict->new(
    'http://example.com/api/avatar/{-list|;|guid}/{selector}/{-join|;|size,view,emotion,dimension,transparent,type,extension}'
);

my %uri_params = $t->extract(
    'http://example.com/api/avatar/100;200;350/@self/size=large;view=entire;transparent=true'
);

print dump(\%uri_params);

__END__
{
  dimension   => undef,
  emotion     => undef,
  extension   => undef,
  guid        => [100, 200, 350],
  selector    => "\@self",
  size        => "large",
  transparent => "true",
  type        => undef,
  view        => "entire",
}

みたいに取れますよっと。

0.03 より loose になってるので互換性の面で難がある場合がありますのでご注意下さいませ。

ちなみにこれで何をしたいかなんだけど、もちろん RESTful API で使うんですけど、HTTP::Router 使った API 専用の薄い WAF を作って使いたいってのがあって、その為にまずは extract が厳格過ぎるってのを直しつつ、次は HTTP::Router の Any::Moose を止めると言う方向性でやりたいなーなんて思ってたりします。

2009-10-17

OpenSocial mobile のシーケンス

先日の idcon #6 にて発表した際に使ったシーケンスです。資料自体は大分グレーなので公開しませんw

例によってシーケンスのテンプレとして WebSequenceDiagrams - Draw sequence diagrams online in seconds こちらもご利用下さい。

2009-04-29

SocialWeb Japan #2

行ってきました。以下殴り書きのメモ。

smart.fm (matake さん)

  • Social Learning Platform を目指す。
  • Container & RESTful API (OpenSocial Container)
    • OpenSocial Container になる事も考慮に入れてるみたい
  • microformats
    • Web上の学習コンテンツの標準化。hVocabulary ってのを提案している
  • Freebase*1 のようなセマンティックなサイトを目指している
感想

smart.fm は思いつく限り色々手を出してるなと思った。

リクルートの OpenID への取り組み (kawa.net さん)

ラボの最初のミッションは CGM を作ってみる。

C-team の話

C-team, クリック率の高いバナーを最速で発見するアルゴリズムを用いて、効果が落ちてきたバナーを差し替える

このサービスの中に二つのソーシャルがある。163個のバナーがある。

C-team ではバナーを登録制で(一個500円とか)作ってもらう。CTR が高い人にお金払ってる。

OpenID 対応サービス

ATND, shiori.cc, 旅箱, コマーシャライザー

独自のID体系を持たない場合の問題点。

感想

とりあえず OpenID の利用事例としては多数の例を持つので参考にはなった。独自のID体系云々ってのは、以前自分も書いてるけど RP になる場合、当然 OP に依存しきって使えなくなるなんて懸念がぬぐえないのであれば、独自に ID 体系も持ちつつ受け入れるべきだよねと。

goo ホーム (橋本さん)

5月中旬にリニューアル、ガジェットが使える OpenSocial v0.8.1 に対応。

RESTful API には対応していない。

Goo 以外のサービスからの更新情報も取り込める

mixiの一般の人が使えるようになる前に使える

goo 全体がソーシャル化されていく。kai をテスト導入してるとのこと。

感想

goo ホームが現時点で日本の OpenSocial 実装として最も優れていると言うのは業界の人の中では常識?w

多数のサービスに横断的にソーシャルグラフを適用していくってのは昨日今日始まった話ではないとは言え、今後こうした動きが加速していくんだろうなと。またその為の道具として、OpenSocial ってのは使えると思った。

OpenSocial 云々そのものより、どのサービスに何を適用してどう面白くなったのかが一番知りたいところ。苦労した点も含めて。

mixi (よういちろうさん)

4/22 時点で1200名の開発者、300以上のアプリ。

全国大会ではなくマイミク大会と言う規模感を狙ってる。

起爆剤として用意したのは、広告、課金、ファンドの三つ。

広告

Canvas view で広告掲載可能。ユーザー保護のために掲載ルールを決める。

mixi アプリオフィシャルアドプログラム (PV に応じて SAP に対して支払う)

1pv = 0.01 円

課金

mixi ペイメント API

SAP : mixi = 8 : 2

手数料は引かれる

ファンド

なんか一個既に投資してる会社がある。

スケジュール
  • 2009/8 mixi アプリ提供
  • 2009/9 mixi アプリモバイル、mixi アドパートナーズ
  • 2009/10 モバイル課金
感想

着々と手を打ってきてるなーと。それ以外はまぁ概ね去年から既に知っていた内容なので驚きは無い。

また mixi アプリモバイルの仕様だけど、一般開発者は手を出せる内容じゃないねーと言う感じではある。

PC 版もある程度の成功はするんだろうけども。。。

Yahoo! (寺岡さん)

IPA未踏出身者の方。昔はエンジニアだったけど今は企画者。

Y! JAPAN のソーシャル化って?

開示できる数字と技術トピックもありません。

4つの重点領域

余り強くない領域と読み替えても構わない。

  • Everywhere 化 (PC 以外のデバイスにも積極展開)
  • オープン化
  • 地域、生活圏情報
  • ソーシャルメディア化
    • メディア化 (メディア価値)
    • ソーシャル化 (コミュニケーション自体の価値)
    • つながりの価値

Y! は 150 くらいサービスある

関連しそうなのは

  • ブログ (200万登録ユーザー)
  • ログール (あしあと)
    • MyBlogLog
  • ブックマーク
    • 公開非公開をブクマごとに出来る *2
  • 占い
    • 私の占いカルテ
    • 友達リストに居る人
    • 今日の相性でお友達ピックアップ
  • ベビー
    • キュート (はてなスターみたいの)
  • 検定
  • ズバリ予想
  • バラエティ
  • プロフィール
    • ここのTOP自体がアクティビティストリームになってる
    • モバイルもある
  • メッセンジャー
    • MSN よりも若干多い(NetRationg的に)
    • ここにもアクティビティストリームが
  • メール
    • ここでもフィードのチェックが出来る
  • トップ
    • 個人ボックス
    • 友達の最新情報
どんなことを考えてやっているか

全てのサービスでソーシャルといっても求めているものが違う

多様性と共通化の折り合い

一方的なもの(1way)、双方向(2way)、1対多(Nway)がつながりのモデル。

承認がいるか、公開かどうか

Facebook は統一されたユーザー体験

Y! は分断されていた

再利用可能なネットワークであることの価値

但し全てが同じネットワークである事が良いとは思っていない

人中心の動線

人のつながりを軸とした動線・回遊性を模索している

ソーシャルUU

UB
20,526万UB (Unique Browser)
UU
2257万ID
SUU
つながりのある UU 非公開

何かしらのつながりを持っているユーザーのカウントを取っている

平均に比べて活発な活動をしているし、購買状況も良い。

まだまだソーシャル化という意味では出来る余地があって、コミュニケーション密度はもっと高められる。

バックエンド
  • Identity (Profile & 2way connection)
  • Favorite (1way)
  • Membership (Nway)
  • Vitality (activity feed)
    • Activities API
  • Notice
    • Message API

投稿系などは省略、まだ社外公開されてない

Social UED
  • レギュレーション
    • BE重要だけど、FE重要 *3
    • ローカルコンテキスト(サービス)と、共通レギュレーション(Y!J全体)のバランスが難しい
  • モジュール
    • ユーザーバッジ (ACL 考慮して)
    • フィードモジュール

Social PF 利用サービス大量に。

苦労している事
  • ソーシャル化の効果を売り上げ、利益で他の要因と切り分けて数値化することが難しい
    • いずれのKPIも売り上げ直結目標じゃない
    • ARPU でみると他の要因との切り分けが困難
  • 金額換算したリターンが他の社内ビジネス・施策より低い
部分最適(サービス) vs 全体最適(Y!J 全体)
  • 開発チームが別だったり
    • 開発部門が事業部制やめて一個になった(プレスより)
今後
  • 引き続きPF化
    • 他のコンテナにもどんどん出て行く
  • 社外サービス・デベロッパーとの協業を強化
    • 外部パートナーにY!J の集客力やマネタイズ手段を
  • チャネルごとのコアビジネスへの展開
感想

個人的にむちゃくちゃ面白かった。多分、やりたい事とか目指す方向性が近いんだろうなーと。

スライド中で出てきたんだけど、Identity, Connection (つながり) , Activity (新着) を異なる色で表現するとIA的に分かりやすいかもしれない。

少なくともどういうものを適用しようとしていてそのジャンル分けを明確にした上で分類を行い、一貫性を出すとかあるべき場所に置くとか、そういう努力は常日頃からしないといけないんだろうなと改めて思った件。

個人的に今所属している会社と Y! や goo ってのは若干似た要素があって、非常に参考になった。

と言う訳で運営のえーじさん、乙です。

次回は運営をちゃんと手伝います><

*1:Wikipedia を構造化したサイト

*2:一見我々にははてブマンセー的な空気があるけど実は Y! ブックマークのが市民権がある

*3:社内用語?良く分からん

2008-12-11 分かりやすい餌に食いついた

OpenID, OAuth, OpenSocial とかその辺りを包括的に話すコミュニティが出来ました

昨日の idcon #4 で agektmr さんと話してて、題目の通り DataPortability 的な何かを横断的に話せるコミュニティ無いから作ってみたよーと言う話を聞いたので、今日から具体的に動き始めてみました。

と言う訳で Google Group と IRC をとりあえず開設。

その辺りに興味のある人や、思いっきり実装してますぜって人まで広く参加して頂けるといいなと思います。

来年一月くらいに、勉強会的な何かを開きたいと思います。