私は一群のウェブアプリを一から作成しようとしています。（概要についてはhttp://50pop.com/codeを参照してください。）フロントエンドWebサイト、スマートフォンアプリ、バックエンドWebサービスなど、さまざまなクライアントからアクセスできるようにしたいので、それぞれのJSON REST API。

また、私はバックエンドで作業することを好むので、純粋にAPIに焦点を当て、ウェブサイト、iPhone、Android、その他のアプリなど、フロントエンドUIを作成するために誰かを雇うことを夢見ています。

私が取るべきアプローチを決めるのを手伝ってください：

共に歩む

非常に標準的なRails Webアプリを作成します。コントローラーで、response_withスイッチを実行して、JSONまたはHTMLを提供します。JSON応答は私のAPIです。

プロ：先例がたくさん。このように物事を行うための素晴らしい基準と多くの例。

欠点： APIがWebアプリと同じである必要はありません。if / then respond_withスイッチアプローチは好きではありません。2つの非常に異なるもの（UI + API）の混合。

RESTサーバー+ JAVASCRIPT-HEAVYクライアント

JSONのみのREST APIサーバーを作成します。クライアント側JavaScriptのBackboneまたはEmber.jsを使用してAPIに直接アクセスし、ブラウザーにテンプレートを表示します。

プロ： APIとクライアントの分離が大好きです。賢い人々は、これが進むべき道だと言っています。理論的には素晴らしい。最先端でエキサイティングなようです。

欠点：先例はあまりありません。これの多くの例はうまくいっていません。公開されている例（twitter.com）は遅いと感じており、このアプローチから切り替えさえしています。

RESTサーバー+サーバー側HTMLクライアント

JSONのみのREST APIサーバーを作成します。REST APIのみにアクセスする基本的なHTML Webサイトクライアントを作成します。クライアント側のJavaScriptの削減。

プロ： APIとクライアントの分離が大好きです。ただし、プレーンHTML5を提供することは、まったく簡単で、クライアントに負荷をかけません。

欠点：先例はあまりありません。これの多くの例はうまくいっていません。フレームワークもこれをサポートしていません。それへのアプローチ方法がわからない。

特に理論だけではなく、経験からのアドバイスを探しています。

で無限、我々はオプション＃2との深い行ってきたと何千人もの生徒にそれを展開しました。サーバーはJSON REST API（Scala + MongoDB）であり、すべてのクライアントコードはCloudFrontから直接提供されます（つまり、www.boundless.comはCloudFrontの単なるエイリアスです）。

長所：

• 最先端/エキサイティング
• 費用対効果が高い：APIは、独自のWebクライアント、モバイルクライアント、サードパーティアクセスなどの基盤を提供します。
• 非常に高速なサイト読み込み/ページ遷移

短所：

• SEOフレンドリーではありません。多くの作業が必要です。
• 70％のJavaScriptであるサイト体験の現実とそれが何を意味するかという現実に対処する準備ができている一流のWebフロントエンドの人々が必要です。

これがすべてのWebアプリの未来だと思います。

Webフロントエンドの人々のためのいくつかの考え（すべての新しさ/チャレンジがこのアーキテクチャに与えられる場所です）：

• CoffeeScript。高品質のコードを作成する方がはるかに簡単です。
• 背骨。あなたのロジックを整理するための素晴らしい方法、そしてアクティブなコミュニティ。
• HAMLC。Haml + CoffeeScriptテンプレート=> JS。
• SASS

シングルページアプリ開発用に調整されたRailsからのアセットパイプラインである「Spar」（シングルページアプリロケットシップ）と呼ばれるフロントエンド開発用のハーネスを構築しました。今後2週間以内にgithubページでオープンソーシングを行い、その使い方と全体的なアーキテクチャの詳細を説明するブログ投稿を掲載します。

更新：

バックボーンに対する人々の懸念に関しては、彼らは過大評価されていると思います。バックボーンは、それが深いフレームワークであるというより、はるかに組織的な原則です。Twitterのサイト自体は、何百万人ものユーザーとレガシーブラウザの隅々までカバーするJavascriptの巨大な獣であり、リアルタイムでツイートを読み込んだり、ガベージコレクションを実行したり、大量のマルチメディアを表示したりします。見て、Twitterは奇妙なものです。JSを介して提供される非常に複雑なアプリは、非常にうまく機能しています。

そして、アーキテクチャの選択は、完全に目標に依存します。複数のクライアントをサポートする最速の方法を探していて、優れたフロントエンドの人材にアクセスできる場合は、スタンドアロンAPIに投資するのが最適です。

とてもよく聞かれました。+1。確かに、これは私にとって将来の役立つリファレンスです。また、@ Aaronやその他のメンバーは、ディスカッションに価値を加えました。Rubyと同様に、この質問は他のプログラミング環境にも同様に当てはまります。

最初の2つのオプションを使用しました。1つ目は多数のアプリケーション用、2つ目は私のオープンソースプロジェクトCowoop用です

オプション1

これは間違いなく最も人気のあるものです。しかし、実装は非常にhttpっぽいです。すべてのAPIの初期コードは、リクエストオブジェクトを処理します。したがって、APIコードは純粋なruby / python /その他の言語コード以上のものです。

オプション2

私はいつもこれが好きでした。

このオプションは、HTMLがサーバー上で生成されるランタイムではないことも意味します。これがオプション2とオプション3の違いです。ただし、ビルドスクリプトを使用して静的HTMLとしてビルドされます。クライアント側に読み込まれると、これらのHTMLはAPIサーバーをJS APIクライアントとして呼び出します。

• 懸念の分離は大きな利点です。そして、バックエンドAPIを実装する好みの（そして私の）バックエンドエキスパートにとって、framework / httpリクエストコードを気にすることなく、通常の言語コードのように簡単にテストできます。

• これは、フロントエンド側で聞こえるほど難しくありません。API呼び出しを実行し、結果のデータ（主にjson）をクライアント側のテンプレートまたはMVCで使用できます。

• サーバー側の処理が少なくなります。それはあなたが一般的なハードウェア/より安価なサーバーに行くかもしれないことを意味します。

• レイヤーを個別にテストしやすくなり、APIドキュメントを生成しやすくなりました。

それはいくつかの欠点があります。

• 多くの開発者は、これが過度に設計されていて理解するのが難しいと感じています。そのため、アーキテクチャが批判される可能性があります。

• i18n / l10nは難しいです。HTMLは本質的に生成されたビルド時間は静的であるため、サポートされている言語ごとに複数のビルドが必要です（これは必ずしも悪いことではありません）。しかし、それでもl10n / i18nのコーナーケースがあり、注意する必要があります。

オプション3

この場合のバックエンドのコーディングは、2番目のオプションと同じでなければなりません。オプション2のほとんどのポイントはここでも適用されます。

Webページは、サーバー側のテンプレートを使用してランタイムにレンダリングされます。これにより、i18n / l10nはより確立された/受け入れられた技術ではるかに簡単になります。ユーザー、言語、通貨などのページレンダリングに必要ないくつかの重要なコンテキストのhttp呼び出しが1つ少なくなる可能性があります。したがって、サーバー側の処理はレンダリングによって増加しますが、APIサーバーへの少ないhttp呼び出しによって補償される可能性があります。

ページがサーバー上でサーバーレンダリングされるようになったため、フロントエンドはプログラミング環境とより密接に結びついています。これは多くのアプリケーションでは考慮事項ではないかもしれません。

Twitterケース

私が理解しているように、Twitterはサーバー上で最初のページレンダリングを行う可能性がありますが、ページ更新のために、DOMを操作するためのAPI呼び出しとクライアント側テンプレートがまだいくつかあります。そのため、そのような場合は、維持する二重テンプレートがあり、オーバーヘッドと複雑さが増します。Twitterとは異なり、誰もがこのオプションを購入できるわけではありません。

私たちのプロジェクトスタック

たまたまPythonを使っています。RESTの代わりにJsonRPC 2.0を使用しています。RESTをお勧めしますが、JsonRPCのアイデアはさまざまな理由で気に入っています。以下のライブラリを使用しています。オプション2/3を検討している人は、それが役立つと思うかもしれません。

• APIサーバー：Python高速なウェブマイクロフレームワーク-Flask
• フロントエンドサーバー：Nginx
• クライアント側MVC：Knockout.js
• その他の関連ツール/ライブラリ：
  • jquery
  • マネー通貨のAccounting.js
  • Webshim：クロスブラウザーポリフィル
  • director：クライアント側ルーティング
  • sphc：HTML生成

私の結論と勧告

オプション3!。

とにかく、私はオプション2をうまく使用しましたが、今は簡単にするためにオプション3に傾いています。ビルドスクリプトを使用して静的HTMLページを生成し、静的ページの提供に特化した超高速サーバーの1つでそれらを提供することは非常に魅力的です（オプション2）。

gaug.esをビルドするときに、＃2を選択しました。私はAPI（ルビー、シナトラなど）に取り組み、ビジネスパートナーのスティーブスミスはフロントエンド（JavaScriptクライアント）に取り組みました。

長所：

1. 平行してすばやく移動します。スティーブの前に働いていれば、新しい機能のためのAPIを作成し続けることができます。彼が私より先に働いていれば、APIを非常に簡単に偽造してUIを構築することができます。

2. 無料のAPI。アプリのデータにオープンアクセスできることは、すぐに標準機能になりつつあります。最初からAPIを使用する場合は、無料で入手できます。

3. きれいな分離。アプリはクライアントとのAPIと考えるのが良いでしょう。確かに、最初の最も重要なクライアントはWebクライアントかもしれませんが、他のクライアント（iPhone、Android）を簡単に作成できるように設定します。

短所：

1. 下位互換性。これは直接的な質問よりもAPIに関連していますが、APIが公開されたら、それを壊すことはできません。これは、ゆっくりと移動する必要があるという意味ではありませんが、多くの場合、2つの機能を同時に動作させる必要があります。APIまたは新しいフィールドへの追加は問題ありませんが、変更/削除はバージョニングなしで行うべきではありません。

私は今、もう短所を考えることはできません。

結論：APIのリリースを計画している場合は、API + JSクライアントが適しています。

PSまた、リリース前にAPIを完全に文書化することをお勧めします。Gaug.es APIを文書化するプロセスは、

http://get.gaug.es/documentation/api/

＃2と＃3のルートを行くのが好きです。主な理由は、＃1が懸念の分離に違反し、あらゆる種類のものが混在するためです。最終的には、一致するHTMLページなどがないAPIエンドポイントが必要になることがわかり、同じコードベースにHTMLエンドポイントとJSONエンドポイントが混在する小川にたどり着きます。それは恐ろしい混乱に変わります。たとえそのMVPがあったとしても、救う価値がないほどすごく乱雑なので、最終的には書き直す必要があります。

＃2または＃3を使用することで、（ほとんどの場合）同じように動作するAPIを完全に使用できます。これは優れた柔軟性を提供します。私はまだBackbone / ember / whatever / etc.jsで100％販売されていません。私はそれは素晴らしいと思いますが、ツイッターで見ているように、これは最適ではありません。しかし... Twitterは企業にとっても大きな獣であり、何億人ものユーザーがいます。したがって、あらゆる改善は、さまざまなビジネスユニットのさまざまな領域の収益に大きな影響を与える可能性があります。私はスピードだけで決定するより多くがあると思います、そして彼らはそれについて私たちを入れさせません。しかし、それは私の意見です。ただし、私はバックボーンとその競合他社を除外しません。これらのアプリは使いやすく、非常にクリーンで、非常に応答性があります（ほとんどの場合）。

3番目のオプションには、いくつかの有効な魅力もあります。これは、パレートの原則（80/20ルール）に従い、メインマークアップの20％（またはその逆）をサーバーにレンダリングし、残りの部分を実行する優れたJSクライアント（バックボーンなど）を用意する場所です。JSクライアントを介してREST APIと100％通信していない可能性がありますが、必要に応じて、より優れたエクスペリエンスを実現するためにいくつかの作業を行います。

これは「依存する」種類の問題の1つだと思います。答えは、「何をしているのか、誰に仕えているのか、どのような経験をしてもらいたいのか」に依存します。私はあなたが2または3またはそれらのハイブリッドの間で決めることができると思うと仮定すると。

現在、巨大なCMSをオプション1からオプション3に変換する作業をしていますが、順調に進んでいます。サーバー側でマークアップをレンダリングすることを選択したのは、SEOが私たちにとって大きな問題であり、サイトを携帯電話で適切に機能させるためです。

私はクライアントのバックエンドにnode.jsを使用し、手助けをするためにいくつかのモジュールを使用しています。私はプロセスのいくらか早い段階ですが、基盤は整っており、すべてが正しく表示されることを確認するためにデータを調査することです。これが私が使っているものです：

• アプリの基盤を表す。
  （https://github.com/visionmedia/express）
• データのフェッチを要求します。
  （https://github.com/mikeal/request）
• サーバー側でレンダリングされるアンダースコアテンプレート。これらをクライアントで再利用します。
  （https://github.com/documentcloud/underscore）
• UTMLは、アンダースコアのテンプレートをラップして、Expressで動作するようにします。
  （https://github.com/mikefrey/utml）
• Upfrontがテンプレートを収集し、クライアントに送信するテンプレートを選択しましょう。
  （https://github.com/mrDarcyMurphy/upfront）
• Express Exposeは、フェッチされたデータ、一部のモジュール、およびテンプレートをフロントエンドに渡します。
  （https://github.com/visionmedia/express-expose）
• バックボーンは、渡されたデータを飲み込んだ後、フロントエンドでモデルとビューを作成します。
  （https://github.com/documentcloud/backbone）

それがスタックの中核です。私が役立つと思った他のいくつかのモジュール：

• フレック（https // github.com / trek / fleck）
• 瞬間（https // github.com / timrwood / moment）
• スタイラス（https // github.com / LearnBoost / stylus）
• smoosh（https // github.com / fat / smoosh）
  … うめき声（https // github.com / cowboy / grunt）を調べていますが
• コンソールトレース（//github.com/LearnBoost/console-trace）。

いいえ、私はコーヒースクリプトを使用していません。

このオプションは私には本当にうまく機能しています。APIから取得したデータは適切に構造化されているため、バックエンドのモデルは存在せず、フロントエンドにそのまま渡します。唯一の例外は、レンダリングモデルを1つ追加して、レンダリングをよりスマートで軽量にするレイアウトモデルです。私はそのために特別なモデルライブラリを使用せず、初期化に必要なものを追加してそれ自体を返す関数を使用しました。

（奇妙なリンクについては申し訳ありませんが、私はスタックオーバーフローのためにn00bでは多すぎて私にそれを投稿させることができません）

＃3の次のバリアントを使用します。JSONのみのREST APIサーバーを作成します。HTMLウェブサイトサーバーを作成します。HTML Webサーバーは、バリエーションのように、REST APIサーバーのクライアントではありません。代わりに、2つはピアです。表面のすぐ下には、2つのサーバーに必要な機能を提供する内部APIがあります。

私たちは前例を知らないので、それは一種の実験的なものです。これまでのところ（ベータに入るところ）、かなりうまくいきました。

私は通常、2番目のオプションとして、Railsを使用してAPIを作成し、JSのバックボーンを使用します。ActiveAdminを使用して、無料で管理パネルを取得することもできます。この種のバックエンドを備えた数十のモバイルアプリを出荷しました。ただし、アプリがインタラクティブかどうかに大きく依存します。

最後のRubyDay.itでこのアプローチに関するプレゼンテーションを行いました：http : //www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

3番目のオプションでは、2番目のオプションの応答性を取得するために、Github と同じようにpajaxを試すことをお勧めします。

ここで説明した2番目のアプローチを取る3か月のプロジェクトに、約2か月かかります。前面にbackbone.jsがあるRESTful APIサーバー側を使用します。Handlebars.jsはテンプレートを管理し、jQueryはAJAXおよびDOM操作を処理します。古いブラウザと検索スパイダーの場合、サーバー側のレンダリングにフォールバックしましたが、Mozilla Rhinoを使用するHandlebarsフロントエンドと同じHTMLテンプレートを使用しています。

私たちはさまざまな理由でこのアプローチを選択しましたが、まだ広範囲で証明されていないため、少しリスクがあることを十分に認識しています。すべて同じですが、これまでのところすべてがかなりスムーズに進んでいます。

これまでは1つのAPIで作業してきましたが、プロジェクトの次のフェーズでは、2番目のAPIで作業します。1つ目は大量のデータ用で、2つ目はAPIを介したCMSのように機能します。

この2つのプロジェクトを完全に独立して動作させることは、このインフラストラクチャを選択する際の重要な考慮事項でした。依存関係のないさまざまな独立したリソースをマッシュアップするアーキテクチャを探しているなら、これは一見の価値があるアプローチです。

私はRubyの人ではないので、他のアプローチについてはコメントできません。時にはリスクを冒しても大丈夫です。それ以外の場合は、安全にプレイすることをお勧めします。プロジェクトのタイプに応じて、自分自身を理解します。

ここであなたの選択で幸運を祈ります。他の人が共有しているものも確認してください。

私のウェブサイトが私のデータの100％CRUD実装になる予定がない場合、私は＃3が好きです。これはまだ起こりません。

私はシナトラを好み、アプリをいくつかの異なるラックアプリに分割し、目的を変えます。APIに必要なものをカバーするAPI固有のラックアプリを作成します。次に、おそらく私のWebページを表示するユーザーラックアプリです。必要に応じて、そのバージョンがAPIにクエリを実行することもありますが、通常はHTMLサイトにのみ関係します。

私はそれについて心配する必要はなく、必要に応じてユーザー側から永続層クエリを実行します。完全な分離を作成することに過度に関心はありません。それらは通常、さまざまな目的を果たします。

これは、複数のラックアプリを使用する非常に簡単な例です。そこに簡単なjqueryの例を追加して、APIアプリにヒットするのを確認しました。シナトラと、さまざまな目的で複数のラックアプリをマウントすることで、それがいかに簡単であるかがわかります。

https://github.com/dusty/multi-rack-app-app

ここですでにいくつかの素晴らしい答えがあります-私は間違いなく＃2または＃3をお勧めします-分離は概念的には良いですが、実際にもそうです。

APIの負荷やトラフィックのパターンなどを予測するのは難しい場合があり、APIを個別に提供しているお客様がプロビジョニングとスケーリングを行うのが簡単になります。人間のWebアクセスパターンに手を加える必要がある場合は、それほど簡単ではありません。また、APIの使用状況は、Webクライアントよりもはるかに速くスケールアップする可能性があり、作業の方向性を確認できます。

＃2＃3の間では、それは本当にあなたの目標に依存します-＃2はおそらくwebappsの未来であると私は同意します-しかし、そのチャネルが多くの1つになるだけなら、もっと簡単なものを望んでいるでしょう！

atyourservice.com.cyについては、特にこの部分をカバーするために、サーバー側でレンダリングされたページのテンプレートを使用しています。また、ページの読み込み後の対話にAPIを使用します。私たちのフレームワークはMVCなので、すべてのコントローラー機能がjson出力とhtml出力に複製されます。テンプレートはクリーンでオブジェクトのみを受け取ります。これは数秒でjsテンプレートに変換できます。サーバーサイドのテンプレートは常に維持し、リクエストに応じてjsに再変換します。

同形レンダリングとプログレッシブ拡張。これは、オプション3であなたが向かったと思います。

同型レンダリングとは、クライアント側のコードで使用するのと同じテンプレートを使用してサーバー側でマークアップを生成することを意味します。サーバー側とクライアント側の実装が適切なテンプレート言語を選択してください。ユーザー向けに完全に焼き付けたhtmlを作成し、ネットワークに送信します。キャッシングも使用します。

プログレッシブエンハンスメントとは、すべてのリソースをダウンロードし、クライアントの機能を決定できるようになったら、クライアント側の実行とレンダリングおよびイベントのリスニングを開始することを意味します。アクセシビリティと下位互換性のために、可能な場合は常にクライアントスクリプトのない機能的な機能にフォールバックします。

はい、もちろん、このアプリの機能のためにスタンドアロンのjson apiを作成します。ただし、静的HTMLドキュメントとして正常に機能するものに対してjson APIを作成するまでは、遠くまで行ってください。

RESTサーバー+ JavaScriptを多用したクライアントは、私が最近の仕事で従った原則でした。

RESTサーバーはnode.js + Express + MongoDB（非常に優れた書き込みパフォーマンス）+ Mongoose ODM（データのモデリングに最適で、検証が含まれています）+ CoffeeScript（代わりにES2015に移行します）で実装されました。Node.jsは、他の考えられるサーバー側のテクノロジーと比べて比較的新しい可能性がありますが、それにより、支払いが統合された堅固なAPIを書くことが可能になりました。

私が使用してきましたEmber.jsを JavaScriptフレームワークとして、アプリケーション・ロジックのほとんどは、ブラウザで実行されました。私はCSSの前処理にSASS（具体的にはSCSS）を使用しました。

Emberは、強力なコミュニティに支えられた成熟したフレームワークです。これは非常に強力なフレームワークであり、新しいGlimmerレンダリングエンジン（Reactに触発された）のように、最近パフォーマンスに焦点を当てた多くの作業が行われています。

Ember Core TeamはFastBootを開発中です。FastBootを使用すると、サーバー側（具体的にはnode.js）でJavaScript Emberロジックを実行し、アプリケーションの事前レンダリングされたHTML（通常はブラウザーで実行されます）をユーザーに送信できます。ページが表示されるのをそれほど長く待たないので、SEOとユーザーエクスペリエンスに最適です。

Ember CLIは、コードの整理に役立つ優れたツールであり、コードベースの拡大に合わせて拡張できました。Emberには独自のアドオンエコシステムもあり、さまざまなEmberアドオンから選択できます。Bootstrap（私の場合）またはFoundationを簡単に取得して、アプリに追加できます。

すべてをExpress経由で提供するのではなく、nginxを使用して画像とJavaScriptの多いクライアントを提供することにしました。私の場合、nginxプロキシの使用が役に立ちました：

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

プロ：APIとクライアントの分離が大好きです。賢い人々は、これが進むべき道であると言います。理論的には素晴らしい。最先端でエキサイティングなようです。

それは実際にも素晴らしいと言えます。REST APIを分離するもう1つの利点は、後で別のアプリケーションに再利用できることです。完全な世界では、同じREST APIをWebページだけでなく、作成する場合はモバイルアプリケーションにも使用できるはずです。

欠点：先例はあまりありません。これの多くの例はうまくいっていません。公開されている例（twitter.com）は遅いと感じており、このアプローチから切り替えさえしています。

状況は今とは異なります。REST APIを実行する多くの例と、それを使用する多くのクライアントがあります。

UIをビジネスロジックから分離する優れた方法を提供するため、Infiniformsのオプション＃2のアーキテクチャを採用することにしました。

これの利点は、APIサーバーがWebサーバーから独立してスケーリングできることです。複数のクライアントがある場合、一部のクライアントは電話/タブレットまたはデスクトップベースであるため、WebサーバーはWebサーバーと同じ程度に拡張する必要はありません。

このアプローチは、特に独自のAPIを使用してWebサイトのすべての機能を提供する場合に、APIをユーザーに開放するための優れた基盤も提供します。

非常に良い質問です。これは、この問題のためのリソースがたくさんあるほど今日では非常に一般的なタスクであると思ったので驚いていますが、真実ではありませんでした。

私の考えは次のとおりです：-jsonやレンダリングhtml を返さずに、APIコントローラーとHTMLコントローラーの間で共通のロジックを持ついくつかのモジュールを作成し、このモジュールをHTMLコントローラーとAPIコントローラーの両方に含めて、必要なことをすべて実行します。 ：

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end

私は、Sinatraをベースとして使用し、ActiveRecord / Postgressなどを使用してページルートを提供する（スリムテンプレート）Webアプリケーションが使用できるREST APIを公開するハイブリッドアプローチを採用しました。選択オプションの入力などの初期の開発では、ヘルパーを使用してスリムテンプレートにレンダリングしますが、本番環境に近づくと、ページの読み込み速度などを重視するようになり、REST APIへのAJAX呼び出しに置き換えられます。

Slimで簡単にレンダリングできるものはそのように処理されます（フォームの入力、jQuery.ValidationからのフォームPOSTデータの受信submitHandlerなどはすべてAJAXです）

テストは問題です。現在、JSONデータをRack :: Test POSTテストに渡そうとして困っています。

私は個人的にソリューション（3）を好ん​​で使用しています。それは私の元の（世帯名）雇用者が持っているほぼすべてのサイトで使用されています。つまり、Javascript、ブラウザの癖、フロントエンドをコード化しないことについてすべて知っているフロントエンド開発者を獲得できるということです。彼らは「カールxyzとあなたがいくつかのjsonを手に入れる」ことを知っている必要があるだけで、彼らは出かける。

その間、あなたのヘビー級のバックエンドの人たちはJsonプロバイダーをコード化することができます。これらの人たちはプレゼンテーションについてまったく考える必要はなく、代わりに不安定なバックエンド、タイムアウト、適切なエラー処理、データベース接続プール、スレッド化、スケーリングなどについて心配します。

オプション3は、優れた堅牢な3層アーキテクチャを提供します。これは、フロントエンドから吐き出すものがSEOフレンドリーであり、古いまたは新しいブラウザー（およびJSがオフになっているブラウザー）で動作するように作成でき、必要に応じてJavaScriptクライアント側のテンプレートにすることもできます（したがって、静的なHTMLで古いbrowsers / googlebotを処理するなどのことを行いますが、最新のChromeブラウザなどを使用しているユーザーに、JSで構築された動的なエクスペリエンスを送信します。

私がオプション3を見たすべてのケースで、これは、特にプロジェクト間で転送できない一部のPHPのカスタム実装であり、オープンソースの土地への出入りは言うまでもありません。最近ではPHPがRuby / Railsに置き換えられた可能性がありますが、同じようなことが今でも当てはまります。

FWIW、$ current_employerはいくつかの重要な場所でオプション3を使用できます。何かを構築するための優れたRubyフレームワークを探しています。たくさんのGemを一緒に接着できると確信していますが、テンプレート化、「カーリング」、オプションの認証、オプションのmemcache / nosql接続キャッシングソリューションを幅広く提供する単一の製品を好みます。そこには私は首尾一貫したものを見つけるのに失敗しています:-(

RailsでのJSON APIの構築は最初のクラスであり、JSONAPI :: Resources gemは、http： //jsonapi.org仕様のAPIの面倒な作業を行います。