☰

REST JSON API サーバーとクライアントを分離しますか? [closed] 質問する

tag-icon • tag-icon ruby-on-rails-3 rest backbone.js sinatra ember.js
REST JSON API サーバーとクライアントを分離しますか? [closed] 質問する

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

また、私はバックエンドでの作業を好むので、純粋に API に集中し、Web サイト、iPhone、Android、その他のアプリのフロントエンド UI を作成するために他の人を雇うことを夢見ています。

どのようなアプローチを取るべきか決めるのを手伝ってください:

レールで一緒に

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

利点:前例がたくさんあります。優れた標準と、このように物事を行う例がたくさんあります。

短所: API を必ずしも Web アプリと同じにする必要はありません。if/then respond_with スイッチ アプローチは好きではありません。2 つの非常に異なるもの (UI + API) を混在させています。

REST サーバー + JavaScript を多用するクライアント

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

賛成: API とクライアントの分離が気に入っています。賢い人たちは、これが正しい方法だと言っています。理論的には素晴らしいです。最先端でエキサイティングなようです。

短所:前例があまりありません。これがうまく実行された例は多くありません。公開されている例 (twitter.com) は動作が遅く、このアプローチから切り替えているところもあります。

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

JSON のみの REST API サーバーを作成します。REST API のみにアクセスする基本的な HTML ウェブサイト クライアントを作成します。クライアント側の JavaScript が少なくなります。

賛成: API とクライアントの分離は気に入っています。ただし、プレーン HTML5 を提供するのは非常に確実で、クライアント集約的ではありません。

短所:前例があまりありません。これがうまく実行された例はあまりありません。フレームワークもこれをサポートしていません。どのようにアプローチすればよいかわかりません。

特に、理論だけでなく経験に基づいたアドバイスを求めています。

ベストアンサー1

で無限私たちはオプション 2 を徹底的に検討し、何千人もの学生に展開しました。私たちのサーバーは JSON REST API (Scala + MongoDB) であり、すべてのクライアント コードは CloudFront から直接提供されます (つまり、www.boundless.com は CloudFront のエイリアスです)。

長所:

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

短所:

  • さらに多くの作業を行わないと SEO に対応できません。
  • 70% が JavaScript であるサイト エクスペリエンスの現実とその意味に対処できる、一流の Web フロントエンド担当者が必要です。

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

Web フロントエンドの担当者向けの考え (このアーキテクチャでは、すべての新しさと課題がここにあります):

  • CoffeeScript。高品質なコードを作成するのがはるかに簡単になります。
  • バックボーン。ロジックを整理する優れた方法、そしてアクティブなコミュニティ。
  • Haml + CoffeeScript テンプレート => JS。
  • サス

私たちはフロントエンド開発用のハーネス「Spar」（Single Page App Rocketship）を構築しました。これは実質的にはシングルページアプリ開発用に調整されたRailsのアセットパイプラインです。今後数週間以内にオープンソース化する予定です。ギットハブページと、その使用方法と全体的なアーキテクチャをより詳しく説明したブログ投稿があります。

アップデート：

Backbone に関する人々の懸念については、過大評価されていると思います。Backbone は、深いフレームワークというよりも、組織化の原則です。Twitter のサイト自体は、数百万のユーザーと従来のブラウザーのあらゆるコーナーケースをカバーする巨大な JavaScript の塊であり、ツイートをリアルタイムで読み込み、ガベージ コレクションを実行し、多くのマルチメディアを表示するなどしています。私が見たすべての「純粋な」 js サイトの中で、Twitter は異質です。JS 経由で配信され、非常にうまく機能している、非常に複雑なアプリは数多くあります。

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

おすすめ記事