OAuth のアイデアに kazuho さんからツッコミをいただいた

[あとで]タグがついた id:kazuhooku さんのブクマにスターを付けたら、エントリでツッコミをいただいた。

なんとなく書いてくれると嬉しいなという軽い気持ちだったのですが、催促したみたいで申し訳ないです。

OAuth が使えるということはサーバサイドでマッシュアップが可能だということであり、そのような状況下において、あえてクライアントサイドでマッシュアップを行うメリットがあるのか (ユーザーに公開非公開の決定権を与えたいのであれば、任意のサイトと OAuth を可能にすればいいだけ)。

データを組み合わせるのであればサーバサイドでいろいろな演算を行いたいだろうと思うし、そこをあえて、可能性が限定されるクライアントサイドで行う必然性があるユーセージモデルが自分には見えません。

OAuth が使えるならサーバ同士で直接データをやり取りすればいいのに、わざわざクライアント側でやる必要あるの？というツッコミだと理解しました。 僕もそれほどちゃんと考えていなかったので、この機会に考えてみました。

• 負荷軽減 … Consumer 側に負荷をかけたくない場合。 Consumer が Provider 側に接続するためのオーバーヘッドを User に代行させる。
• Provider が提供する WebAPI の制限 … Google Search API が JavaScript だけの提供になったように、 WebAPI として JavaScript のみを提供する場合

例えば、 GMail のような Web メールのサービス提供者が、アドレス帳を JavaScript の WebAPI として提供するような場合を考えました。 SNS のサービス提供者が OAuth の Consumer になって、 SNS の招待状を送りたい相手をアドレス帳から選んでもらう。 ここまでは JavaScript で実行して、選択後のアドレスだけを Consumer に送るような場合だと、クライアント側のマッシュアップもありえるのかなと思いました。 まぁ、 OAuth の Signature を生成するのは Consumer なので、負荷軽減の効果は少し微妙ですが。

※ SNS とアドレス帳の関係は yaari.comからの招待状を無視してください (recompile.net)に書かれていることをちょっとヒントにしました。