読者です 読者をやめる 読者になる 読者になる

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の提供メカニズムを直接提供したほうがいいんじゃないかって話。タダ乗りがアレだったらレから金を取るか買ってしまえばいいし、買う場合もデータストアが同じだから比較的楽に統合できる。まあいろいろ問題はあるだろうけど、そういう流れないかな。