web-dev-qa-db-ja.com

REST JSON APIサーバーとクライアントを分けますか？

私は最初からたくさんのWebアプリケーションを作成しようとしています。 （概要については http://50pop.com/code を参照してください。）フロントエンドWebサイト、スマートフォンアプリ、バックエンドWebサービスなど、さまざまなクライアントからアクセスできるようにしたいと思います。だから私は本当にそれぞれのJSON REST AP​​Iが欲しいのです。

また、私はバックエンドに取り組むことを好むので、純粋にAPIに集中し、Webサイト、iPhone、Android、その他のアプリにかかわらず、フロントエンドUIを作るために他の誰かを雇うことを私は夢みています。

どのアプローチをとるべきかを決める手助けをしてください。

レールの中に

非常に標準的なRails Webアプリを作ります。コントローラで、JSONまたはHTMLのいずれかを処理するためにrespond_withスイッチを実行します。 JSONレスポンスは私のAPIです。

Pro：たくさんの先例。優れた標準と、このようにして物事を行う多くの例。

欠点：APIをWebアプリと同じにしたくない場合があります。スイッチアプローチで応答した後に応答しないでください。 2つの非常に異なるものを混在させる（UI + API）。

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

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

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

欠点：あまり前例はありません。これの多くの例はうまくいきませんでした。一般的な例（Twitter.com）は鈍いと感じており、このアプローチから外れることすらあります。

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

JSON専用REST AP​​Iサーバーを作成します。 REST AP​​Iのみにアクセスする基本的なHTML Webサイトクライアントを作成します。クライアントサイドのJavaScriptが少ない。

Pro：APIとクライアントの分離が大好きです。しかし、プレーンなHTML5を提供することは非常に簡単で、クライアントに負担がかかりません。

欠点：あまり前例はありません。これの多くの例はうまくいきませんでした。フレームワークもこれをサポートしていません。どうやってそれに近づくかわからない。

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

ruby-on-rails-3restbackbone.jssinatraember.js
369
sivers

Boundless で、私たちはオプション＃2で深くなり、それを何千人もの学生に広めました。私たちのサーバーはJSON REST AP​​I（Scala + MongoDB）であり、私たちのすべてのクライアントコードはCloudFrontから直接提供されます（例：www.boundless.comはCloudFrontの単なるエイリアスです）。

長所：

  • 最先端/エキサイティング
  • あなたの支出に大いに感銘を与えること：APIはあなた自身のウェブクライアント、モバイルクライアント、サードパーティアクセスなどのための基礎をあなたに与えます。
  • 非常に速い高速サイトロード/ページ遷移

短所：

  • SEOにやさしい/多くの作業なしで準備ができていない。
  • 70％のJavaScriptとそれが何を意味するのかというサイトエクスペリエンスの現実に対処する準備ができている一流のWebフロントエンドの人々が必要です。

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

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

  • CoffeeScript高品質のコードを簡単に作成できます。
  • 背骨。あなたの論理、そして活発なコミュニティをまとめるための素晴らしい方法です。
  • HAMLC Haml + CoffeeScript templates => JS。
  • SASS

フロントエンド開発用のハーネス「Spar」（Single Page App Rocketship）を構築しました。これは、事実上、1ページのアプリケーション開発用に調整されたRailsの資産パイプラインです。 github ページで、今後2、3週間以内にオープンソースになる予定です。また、その使い方と全体的なアーキテクチャについて詳しく説明したブログ記事もあります。

更新：

バックボーンに対する人々の懸念に関して、私は彼らが過大評価されていると思います。バックボーンは深い枠組みよりもはるかに組織的な原則です。 Twitterのサイト自体は、リアルタイムのツイートのロード、ガベージコレクト、大量のマルチメディアの表示などを行う一方で、何百万ものユーザーやレガシーブラウザにわたるあらゆるケースをカバーするJavascriptの巨大な獣です。見て、Twitterは変わったものです。 JSを介して配信された非常に複雑なアプリは非常にうまくいっています。

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

134
Aaron

非常によく尋ねた。 ＋１。確かに、これは私にとって将来の役に立つ参考資料です。また@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ドキュメントを簡単に生成できます。

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

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

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

オプション3

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

Webページはサーバーサイドテンプレートを使用して実行時にレンダリングされます。これにより、より確立された、または認められている技術を用いて国際化/国際化が非常に容易になります。ユーザー、言語、通貨など、ページのレンダリングに必要ないくつかの重要なコンテキストでは、1回少ないHTTP呼び出しで済みます。したがって、サーバー側の処理はレンダリングによって向上しますが、APIサーバーへのHTTP呼び出しが少なくなる可能性があります。

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

Twitterのケース

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

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

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

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

私の結論と提言

オプション3！.

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

47
Shekhar

Gaug.esをビルドするときは＃2を選びました。私はAPI（Ruby、sinatraなど）を担当し、ビジネスパートナーのSteve Smithはフロントエンド（JavaScriptクライアント）を担当しました。

長所：

  1. 並行してすばやく移動します。私がSteveに先んじて働いたなら、私は新機能のためのAPIを作り続けることができました。彼が私の前で働いた場合、彼は非常に簡単にAPIを偽造してUIを構築することができます。

  2. 無料のAPIアプリ内のデータへのオープンアクセスは、すぐに標準機能になりつつあります。あなたがゼロからAPIから始めるなら、あなたは無料でこれを手に入れます。

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

短所：

  1. 後方互換性これはあなたの直接の質問よりもAPIに関連していますが、一旦あなたのAPIがそこに出たならば、あなたはただそれを破ることができないか、あなたはあなたのすべてのクライアントを2つ破ります。これはあなたがゆっくり動かなければならないという意味ではありませんが、それはあなたがしばしば二つのことを一度にうまく機能させる必要があるということを意味します。 APIや新しいフィールドに追加するのは問題ありませんが、変更や削除はバージョン管理なしでは行わないでください。

私は今もうもう短所について考えることはできません。

結論：APIをリリースする予定の場合は、API + JSクライアントが最適な方法です。

P.S APIをリリースする前に完全に文書化することをお勧めします。 Gaug.es APIを文書化するプロセスは、私たちに大きな影響を与えました。

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

28
John Nunemaker

私は＃2と＃3の道を行くのが好きです。主に＃1が懸念の分離に違反し、あらゆる種類のものを混ぜ合わせるためです。最終的には、一致するHTMLページなどを持たないAPIエンドポイントが必要になり、同じコードベースにHTMLとJSONのエンドポイントが混在するようになるでしょう。たとえそのMVPであっても、それはおかしいと思う混乱に変わってしまうでしょう。

＃2または＃3を使用すると、それに関係なく（大部分は）同じように動作するAPIを完全に使用できます。これは大きな柔軟性を提供します。私は100％Backbone/ember/whatever/etc.jsで売っているわけではありません。素晴らしいと思いますが、Twitterで見ているようにこれは最適ではありません。しかし... Twitterはまた会社の巨大な獣であり、何億ものユーザーを抱えています。そのため、あらゆる改善がさまざまな事業部門のさまざまな分野の収益に大きな影響を与える可能性があります。スピードだけでは決まらないことが多いと思います。しかしそれは私の意見です。しかし、私はバックボーンとその競争相手を割り引かない。これらのアプリは、使用するのに最適で、非常にきれいで、非常にレスポンシブです（大部分）。

3番目のオプションにも有効な魅力があります。これが私がPareto原則（80/20規則）に従い、あなたのメインマークアップの20％（あるいはその逆）をサーバー上にレンダリングし、それからNice JSクライアント（バックボーン/ etc）にそれを実行させるところです。 。 JSクライアントを介してRESTapiと100％通信しているわけではありませんが、必要に応じて、より快適な体験を提供するために何らかの作業を行うことになります。

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

10
Donn Felker

私は現在、巨大な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）

それがスタックの中核です。私が参考になった他のいくつかのモジュール：

  • fleck（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から取得したデータはよく構造化されており、フロントエンドにそのまま渡しているため、バックエンドのモデルは存在しません。唯一の例外は、レンダリングをよりスマートで軽量にする単一の属性を追加するというレイアウトモデルです。私はそのために派手なモデルライブラリを使用しませんでした。初期化時に必要なものを追加して自分自身を返す関数だけを使用しました。

（奇妙なリンクをごめんなさい、私は私がその多くを投稿させるためにスタックオーバーフローのために多すぎるn00bです）

7
Darcy Murphy

＃3の次のような変種を使用します。JSON専用REST AP​​Iサーバーを作成します。 HTML Webサイトサーバーを作ります。 HTML Webサーバは、あなたのバリアントのように、REST AP​​Iサーバへのクライアントではありません。代わりに、両者は仲間です。表面からそれほど遠くない、2つのサーバーが必要とする機能を提供する内部APIがあります。

私達はどんな前例も知らないので、それは一種の実験的なものです。これまでのところ（ベータ版に入る）、それはかなりうまくいっています。

7
Thomas Becker

私はたいてい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 を試してみることをお勧めします。

7
Matteo Collina

私はここで概説した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の人ではないので、他の方法についてはコメントできません。時には危険を冒しても大丈夫です。それ以外の場合は安全にプレイする方が良いでしょう。プロジェクトの種類によっては自分で知っているでしょう。

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

6
Iarfhlaith Kelly

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

私はsinatraが好きで、目的を変えていくつかのラックアプリケーションにアプリを分割します。 APIに必要なものをカバーする、API固有のラックアプリを作成します。それから私のWebページを表示するユーザーラックアプリ。時にはそのバージョンが必要に応じてAPIを問い合わせるでしょうが、通常それはちょうどhtmlサイトに関係します。

私はそれについて心配しません、そして、私がそれを必要とするならば、ただユーザー側から永続層クエリをするだけです。私は完全な分離を作成することにあまり関心を持っていません。それらは通常異なる目的を果たすことになるからです。

これは、非常に複数ラックアプリケーションを使用する簡単な例です。私はあなたがそれがAPIアプリに当たるのを見るためにそこにクイックjqueryの例を追加しました。あなたはそれがシナトラと異なる目的で複数のラックアプリをマウントすることでどれほど簡単になることができるかを見ることができます。

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

4
Dusty

ビジネスロジックからUIを切り離すための優れた方法を提供したので、 Infiniforms にはOption＃2のアーキテクチャを採用することにしました。

これの利点は、APIサーバーがWebサーバーから独立して拡張できることです。あなたが複数のクライアントを持っているなら、いくつかのクライアントが電話/タブレットまたはデスクトップベースであるので、ウェブサイトはウェブサーバーと同じ程度に拡大縮小する必要はないでしょう。

このアプローチはまた、特にあなたがあなたのWebサイトのためのすべての機能を提供するためにあなた自身のAPIを使う場合、あなたのユーザにあなたのAPIを公開するための良い基盤を与えます。

1
Karl Gjertsen

非常に素晴らしい質問であり、これは最近では非常に一般的な作業であり、この問題に対するリソースは十分にあると思っていたのに驚いていますが、真実ではないことが判明しました。

私の考えは次のとおりです。-APIコントローラーとHTMLコントローラーの間で共通のロジックを持つモジュールを作成しますwithout jsonを返すか、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
1
Loai Ghoraba

Atyourservice.com.cyでは、特にse部分をカバーするために、サーバーサイドでレンダリングされたページのテンプレートを使用しています。そして、ページロード後のインタラクションにAPIを使用します。私たちのフレームワークはMVCなので、すべてのコントローラー機能はjson出力とhtml出力に複製されます。テンプレートはきれいで、ただオブジェクトを受け取ります。これは数秒でjsテンプレートに変換できます。私たちは常にサーバーサイドのテンプレートを保守し、要求に応じてjsに再変換するだけです。

1
xatzistnr

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

APIの負荷やトラフィックのパターンなどを予測するのは困難な場合があり、APIを個別に提供しているお客様には、プロビジョニングと拡張が容易になります。それを人間のWebアクセスパターンで実行しなければならない場合は、それほど簡単ではありません。また、あなたのAPI利用はあなたのウェブクライアントよりもずっと速くスケールアップすることになるかもしれません、そしてあなたはあなたの努力を指示する場所を見ることができます。

＃2と＃3の間は本当にあなたの目標に依存します - おそらく＃2がWebアプリケーションの未来であると私は同意します - しかしそのチャンネルが多くのうちの1つになるならもっと多分あなたはもっと簡単な何かが欲しいです！

1
steve

同形レンダリングとプログレッシブエンハンスメントそれがオプション3であなたが向かっていたと私は思います。

同形レンダリングクライアントサイドのコードで使用するのと同じテンプレートを使用してサーバーサイドのマークアップを生成することを意味します。優れたサーバーサイドおよびクライアントサイドの実装を持つテンプレート言語を選択してください。ユーザーのために完全に焼き込まれたHTMLを作成して、それをネットワークに送信します。キャッシュも使用してください。

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

はい、もちろん、このアプリの機能のためのスタンドアロンのJSON APIを書く。しかし、静的HTML文書として問題なく動作するものについては、JSON APIを作成してください。

1
sirtimbly

RESTサーバー+ JavaScriptを多用するクライアントが、私の最近の作業で私が従った原則です。

RESTサーバーは node.js + Express + MongoDB （非常に優れた書き込みパフォーマンス）+ Mongoose ODM （に実装されました。データのモデリングに最適で、検証も含まれています）+ CoffeeScript （代わりにES2015に行きます）これは私にとってはうまくいきました。 Node.jsは他の可能なサーバーサイド技術と比較して比較的若いかもしれませんが、支払いを統合した堅実なAPIを書くことを可能にしました。

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

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

Ember Coreチームは FastBoot の開発を進めています。これにより、JavaScript Emberロジックをサーバー側（特にnode.js）で実行し、レンダリング済みのアプリケーションのHTML（通常はユーザーにブラウザで実行します。彼がページが表示されるのをそれほど長く待たないので、それはSEOとユーザーエクスペリエンスにとって素晴らしいです。

Ember CLI あなたのコードを体系化するのを手助けする素晴らしいツールであり、成長するコードベースに合わせてうまく機能しました。 Emberには独自のアドオンエコシステムもあり、さまざまな Ember Addons から選択できます。あなたは簡単に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;
  }
}

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

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

Con：あまり前例はありません。これの多くの例はうまくいきませんでした。一般的な例（Twitter.com）は鈍いと感じており、このアプローチから外れることすらあります。

今は状況が違って見えます。 REST AP​​I +それを消費する多くのクライアントを行う例はたくさんあります。

1
Daniel Kmak

私は個人的に解決策として選択肢（3）を好みます。それは私の元（姓）雇用者が持っているほぼすべてのサイトで使われています。それはあなたがJavascript、ブラウザの癖、そしてあなたのフロントエンドをコード化することについて何も知らないフロントエンドの開発者を得ることができることを意味します。彼らは「cury xyzとjsonを手に入れるでしょう」ということだけを知っていればいいのです。

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

オプション3は、優れた堅牢な3層アーキテクチャを提供します。それはあなたがフロントエンドから吐き出すものがSEOにやさしく、古いか新しいブラウザ（そしてJSがオフになっているもの）で動作するように作られることができ、そして望むならまだJavascriptクライアントサイドテンプレートでありえます静的なHTMLで古いブラウザやgooglebotを扱うなどのことをしますが、最新のChromeブラウザなどを使ってJSで構築された動的な経験を人々に送ります。

私がOption 3を見たすべての場合において、これはいくつかのPHPのカスタム実装でした。これは、プロジェクト間で特に譲渡することはできません。ごく最近になって_ PHPがRuby/Railsに置き換えられたかもしれませんが、同じことがまだ当てはまります。

FWIW、$ current_employerはいくつかの重要な場所でオプション3を使用できます。私は何かを構築するための良いRubyフレームワークを探しています。私はたくさんのgemを接着することができると確信していますが、私はテンプレート化、 'カーリング'、オプション認証、オプションのmemcache/nosql接続キャッシングソリューションを広く提供する単一の製品を望みます。コヒーレントなものを見つけることができません:-(

0
Ralph Bolton

私たちがSinatraをベースとしてActiveRecord/Postgressなどを使ってページルートを提供する（スリムなテンプレート）Webアプリケーションが使用できるREST AP​​Iを公開するハイブリッドアプローチを採用しました。初期の開発段階では、選択オプションの入力はスリムテンプレートへのヘルパーレンダリングを介して行われますが、本番に近づくにつれて、開始時にAJAX AP​​IへのREST呼び出しに置き換えられます。ページ読み込み速度などについてもっと気にするため。

Slimでレンダリングするのが簡単なものはそのように扱われ、そしてもの（jQuery.ValidationのsubmitHandlerなどからフォームにデータを取り込む、フォームPOSTデータを受け取るなど）はすべてAJAXです。

テストは問題です。今のところ私は困惑しています JSONデータをRack :: Test POSTテストに渡そうとしています 。

0
Dave Sag

RailsでJSON APIを構築することが第一級です。JSONAPI:: Resources gemは http://jsonapi.org spec'd APIのために重い作業を行います。

0
pixelhandler