REST APIとかだるくない？って話

なんか、今のWebサービスって

• TwitterとかFacebook、一応FoursquareなどのデカいWebサービスがある
• それらはREST APIで内部の情報を提供している

というのがまず前提にあって(これらのサービスを「デ」と略す)、連携したサービス(レ)を開発する場合、

• 認証系はデのOAuthなどにおんぶにだっこ
• デのユーザーと、そのデータに紐づいたデータをレで持っとく
• デのプロフィールとかソーシャルグラフとかも持ってきたいから、レのクライアントかサーバーがREST APIを使いまくったりする
• デが死んだらレも死ぬ

というのがセオリーだと思う。ただ、近年の流れとして

• スマートフォンのネイティブアプリや、WebでもクライアントサイドMVCが流行してきて、レでもサーバーサイドはAPIを提供するだけになりつつある
• それに呼応する形で、BaaS(Backend as a Service):リッチなクライアントとAPIでやりとりすることを前提に、レ向けに認証系、データストア、クロールなど必要なものを提供するサービスも始まっている

というのがある。こういう流れを見ていると、レにデがREST APIを提供するってモデル自体が古いものに思えてくる。だいたい理由を箇条書きにする。

• どうせデもレも同じ認証を使うんだから、まとめたほうがいい
• デは明らかにデカいデータストアを持ってるんだから、ついでにBaaS的に分けて欲しい
• そのほうがデータの連携もまとめられて良い

つまり、デがレにAPIを提供するんじゃなくて、適切な権限においてデータストアとAPIの提供メカニズムを直接提供したほうがいいんじゃないかって話。タダ乗りがアレだったらレから金を取るか買ってしまえばいいし、買う場合もデータストアが同じだから比較的楽に統合できる。まあいろいろ問題はあるだろうけど、そういう流れないかな。