RailsでWEB APIサーバを作るときのアーキテクチャをどうするか考える

最近のWEBサービスで多いパターンとしてクライアントがブラウザ（PC＆スマホ）とアプリ（AndroidとかiOSとか）のように異るUIを持つクライアントを複数持つものがある。

ブラウザはHTML＋データが必要であり、アプリはデータのみが必要になる。

こんな要件に対応するためのサーバサイドのアーキテクチャとしてはどういったアプローチがあってどれがいいのか？ということを調べて考えたメモ。

参考サイトはここのみ。
http://stackoverflow.com/questions/10941249/separate-rest-json-api-server-and-client

以下は上記サイトの翻訳じゃなくて、途中まで読んだ上での自分なり考えを整理するためのまとめ。

これらのクライアントとデータをやり取りするRailsを用いたサーバサイドの作り方としては

サーバサイドはHTMLもAPIも一緒にRailsで作る
- ヘッダなどでリクエストの種類を判別して、respond_withとかで返却するデータを分ける
サーバサイドはWEB APIサーバに徹する
- ブラウザはJSでAPIを叩き、返却されたデータと予め持っておいたHTMLパーツとでDOMを構築するかたちをとる
上記２つの中間。サーバサイドにAPIとHTMLの受け口を分けて作る

1は最もスタンダード、というか何も考えずに実装に走るとこのかたちになると思う。コントローラがかなりごちゃごちゃになるけど、実装難易度（≠運用保守難易度）としては高くはない。ただ、この方法で前にやったことがあるけど、この手法はコントローラがジェンガみたいになりがちだから好きじゃない。テストも何のテスト書いてるのかわからなくなってくるし。

2はHTMLとAPIの区分けがきっちりできていて個々の実装はシンプルになるし分担もしやすい。が、SEO的に相当工夫しないと厳しいのと、ブラウザ側でUIをすべてコントロールするというのはなかなか厳しそう。かつてのtwitterがこのかたちをとっていたが、今はパフォーマンス的な理由でやめた（トップページだけ？）。

3はサーバサイドの実装はすっきりするけど、コントローラの処理を中心にちょっと冗長的な処理が増えそう。

この話題もご多分に漏れず、どれがいいかという絶対的な基準はなく、サイトの特性や開発リソースの状況によってベストチョイスは変わると思う。ただ、2はtwitterみたいにUIの種類が少ないサイトだったらいいかもしれないけど、このクライアントサイド(ブラウザ＝JS)を操れる人はあまりいなさそうな。。

で、3を採用してみようと思う。１のデメリットは体験済みだし、2はデメリットの大きさが想像しきれない、というかやり切る自信がない。3は1との比較になるが、実装が冗長する分には同じアプリ内で済ませれば極小化できるだろうし、まあ多少冗長化してもトータルの開発コストとしては１より少ないと感じたから。

よし、そうしよう。

追記）続き書いた。RESTful APIとWebサイトを１つのアプリケーションで作る