[解決済み] REST JSON APIのサーバーとクライアントを分離？[クローズド］

質問

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

また、私はバックエンドの仕事が好きなので、APIだけに集中し、フロントエンドのUIは他の人に頼んで、ウェブサイトやiPhone、Androidなどのアプリを作れたらと夢想しています。

どのようなアプローチをとるべきか、ご教授ください。

<ブロッククオート

railsで一緒に

ごく標準的なRailsのWebアプリを作成します。コントローラで、response_withスイッチを使って、JSONかHTMLのどちらかを提供します。JSONのレスポンスが私のAPIになります。

プロです。 前例が多い。素晴らしいスタンダード＆ランプ。この方法でやっている例がたくさんある。

コン APIは必ずしもWebアプリと同じである必要はない。if/then response_with switchのアプローチは好きではありません。2つの全く異なるもの（UI + API）が混在している。

<ブロッククオート

レストサーバー + javascriptを多用するクライアント

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

プロ APIとクライアントを分離しているのが素晴らしい。賢い人たちは、これがいいって言うんだ。理論的には素晴らしい。最先端でエキサイティングな感じがする。

<強い コンです。 前例があまりない。うまくいった例もあまりない。公開されている例（twitter.com）では、低調な印象があり、この方法から切り替えている例もあります。

<ブロッククオート

レストサーバ＋サーバサイドHTMLクライアント

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

プロ APIとクライアントを分離しているのが良いですね。しかし、プレーンなHTML5を提供することは、非常に確実であり、クライアントに負担をかけない。

コン 前例があまりない。うまくいった例もあまりない。フレームワークがあまり対応していない。どのようにアプローチすればよいのかわからない。

特にインセオリーだけでなく、経験からのアドバイスを求めています。

どのように解決するのですか？

で バウンドレス を深く掘り下げ、何千人もの学生に展開しています。私たちのサーバーはJSON REST API（Scala + MongoDB）で、すべてのクライアントコードはCloudFrontから直接提供されています（つまり、www.boundless.com はCloudFrontの単なるエイリアスです）。

長所

• 最先端／エキサイティング
• お得感がいっぱい。APIは、独自のウェブクライアント、モバイルクライアント、サードパーティアクセスなどのための基礎を提供します。
• 非常に サイト読み込み／ページ遷移の高速化

短所

• SEO対策がされていない。
• 70％がjavascriptで構成されるサイト体験とその意味に対応できる、一流のウェブフロントエンド人材が必要です。

これは、すべてのWebアプリケーションの未来だと思います。

Webフロントエンドの人たち（このアーキテクチャでは、すべての新しさや課題がそこにあります）に対するいくつかの考えです。

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

フロントエンド開発用に「Spar」（Single Page App Rocketship）というハーネスを構築しました。 これは、Railsのアセットパイプラインをシングルページアプリ開発用にチューニングしたものです。今後数週間のうちに、私たちの ギズーブ のページで、使い方や全体的なアーキテクチャの詳細を説明したブログ記事を掲載しています。

UPDATE

Backboneに対する人々の懸念についてですが、私は過大評価だと思います。Backboneは、深いフレームワークというよりも、はるかに組織的な原理なのです。Twitterのサイト自体が、何百万人ものユーザーと、レガシーブラウザで、リアルタイムにツイートを読み込みながら、ガベージコレクト、多くのマルチメディアを表示するなど、あらゆるケースをカバーするJavascriptの巨大な獣なのです。私がこれまで見てきた「純粋な」Javascriptサイトの中で、Twitterは異彩を放っています。JSで配信される印象的で複雑なアプリはたくさんあり、とてもうまくいっています。

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