昨日は夏休みでした。
そして気づいたら朝！
↓これ、面白い。
最初の質問の人と同じ事思う。
APIの進捗は、Person/Groups/ActivitiesをGETするところまで。
とりあえずその話は割愛。
コンシューマとサービスプロバイダの関係
コンシューマ => ガジェットを実行するサーバ
サービスプロバイダ => リクエストに対してデータを返すサーバ
こう考えていた。
mixiで言うと、
コンシューマ => http://platform001.mixi.jp/
サービスプロバイダ => http://mixi.jp/
多分違った。
コンシューマ => http://*.mixi-platform.com/
サービスプロバイダ => http://*.mixi-platform.com/
ガジェットを実行してるのはmixi-platform.com。
マイミクとかの情報を取りに行く部分もmixi-platform.com。
コンシューマとサービスプロバイダが同じドメイン。
container.jsのpathに取りにいくらしい。
opensocial-0.8{
path : "http://%host%/social/rpc"
}
↓ここに詳しく書いてある。
Tender Surrender » OpenSocialのOAuthまとめ
ガジェットから他のサービスプロバイダにアクセスする場合は、makeRequestでコンシューマをプロキシとする。
Gadgets API リファレンス - OpenSocial - Google Code #gadgets.io.makeRequest
Inbound OAuthってのは、mixiが法人だけにOAuthのコンシューマキーを発行してるのアレの事かな？
その時にmixi-platform.comがサービスプロバイダで、発行先法人がコンシューマ。
Shindigにはサービスプロバイダの型が出来ている
Shindigのソースを(初めて)見てみた。
Shindigって、ガジェット実行だけじゃなくてサービスプロバイダとしてRPCでデータを返す部分も型だけは出来てた。
おそらく、自分で書き換えろって事だと思う。
根本的な部分が解ってなかった。
リクエストURLによってサーブレットを振り分けてるっぽい。
/social/rest の場合は src/social/servlet/DataServiceServlet.php
/social/rpc の場合は src/social/servlet/JsonRpcServlet.php
Restの場合、DataServiceServletを引数なしでインスタンス化して、リクエストにあわせてdoGet()/doPost()/doPut()/doDelete()のいずれかを実行する。
RPCの場合、JsonRpcServletを引数なしでインスタンス化して、リクエストにあわせてdoGet()/doPost()のいずれかを実行する。
そういうクラスを作って置き換えればいいらしい。
サービスプロバイダを作るにしても、そういう作りの方がよさそうだ。
DataServiceServlet/JsonRpcServlet共にApiServletを継承していて、ApiServletは24ファイルrequireしてる。
大きすぎる。
読むのめんどくさい。
自慢じゃないが、OAuthのライブラリを使わずにfsockopenでOAuth認証を行うプログラムを作る程人様の作ったプログラムを読むのが苦手。
参照渡しとかあるともう読む気にならない。
src/social/servlet/ をまるまる自分で作った方がよさそうだ。
あと、SecurityTokenの発行/認証の仕方が解らん。
それが解らないと認証できない。
というか、まだRPCはやってなかった。
データベースへのアクセス部分は共通として、リクエストをパースする部分だけを2つ分けよう。
根本的な部分が解ってなかったのが原因で、いろんな部分を変える事になってしまった。
まぁまずはRESTfulで通信する外部サーバからだけど。
それにしてもShindigのindex.phpの書き方、専門学校2年の時にPHP教えてくれてた先生の書き方にやたらと似てる気がする。
コンシューマ側をやろうとしてる人がいた
実は、ガジェットとかあんまり作った事がなく、そっち方面がさっぱり。
で、ここの方はまさに解らない部分の事を(手探りで)書いてくれてる。
コードも書いてくれてて、解りやすい。
長くてまだ全部は読んでないけど。
ただ、↓こういう部分は、
〜〜 + ' ';
↓こうしないと動かなかった。
〜〜 + '<br />';
