372

たくさんのWebアプリを最初から作成しようとしています。（概要については、http： //50pop.com/codeを参照してください。）フロントエンドWebサイト、スマートフォンアプリ、バックエンドWebサービスなど、さまざまなクライアントからアクセスできるようにしたいと考えています。それぞれのJSONRESTAPI。

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

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

Railsで一緒に

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

プロ：前例がたくさんあります。素晴らしい基準とこの方法で物事を行う多くの例。

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

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

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

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

短所：あまり前例はありません。これの多くの例はうまくいきませんでした。公開されている例（twitter.com）は動きが鈍く、このアプローチから離れつつあります。

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

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

プロ： APIとクライアントの分離が大好きです。しかし、プレーンHTML5を提供することは非常に確実であり、クライアントを集中的に使用することはありません。

短所：あまり前例はありません。これの多くの例はうまくいきませんでした。フレームワークはこれもサポートしていません。アプローチ方法がわからない。

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

4

18 に答える 18

138

Boundlessでは、オプション #2 を深く掘り下げ、何千人もの学生に展開しました。サーバーは JSON REST API (Scala + MongoDB) であり、すべてのクライアント コードは CloudFront から直接提供されます (つまり、www.boundless.com は CloudFront の単なるエイリアスです)。

長所：

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

短所：

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

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

Web フロント エンドの人々 (すべての新しさ/課題がこのアーキテクチャに与えられている場所) へのいくつかの考え:

  • コーヒースクリプト。高品質のコードを簡単に作成できます。
  • 背骨。ロジックとアクティブなコミュニティを整理する優れた方法です。
  • HAMLC。Haml + CoffeeScript テンプレート => JS.
  • SASS

「Spar」(Single Page App Rocketship) と呼ばれるフロントエンド開発用のハーネスを作成しました。これは、シングル ページ アプリ開発用に調整された Rails からのアセット パイプラインです。今後数週間以内にgithubページでオープンソースを公開し、その使用方法と全体的なアーキテクチャをより詳細に説明するブログ投稿を行います。

アップデート：

Backbone に対する人々の懸念に関しては、過大評価されていると思います。バックボーンは、深いフレームワークというよりも、組織の原則です。Twitter のサイト自体は、何百万人ものユーザーとレガシー ブラウザのすべてのコーナー ケースをカバーする Javascript の巨大な獣であり、リアルタイムでツイートをロードし、ガベージ コレクションを行い、多数のマルチメディアを表示するなどしています。見て、Twitterは奇妙なものです。JS を介して配信された非常に複雑なアプリが数多くあり、非常にうまく機能しています。

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

于 2012-06-07T23:54:25.760 に答える
49

とてもよく聞かれました。+1。確かに、これは私にとって将来の有用なリファレンスです。また、@Aaron などは議論に価値を追加しました。Ruby と同様に、この質問は他のプログラミング環境にも等しく当てはまります。

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

オプション1

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

オプション 2

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

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

  • 関心の分離は大きな利点です。また、バックエンドの専門家がバックエンド API を実装し、フレームワークや http リクエスト コードを気にすることなく、通常の言語コードと同じように簡単にテストできることは、あなたの好み (および私の好み) です。

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

  • サーバー側の処理が少なくなります。つまり、コモディティ ハードウェア/安価なサーバーを選択できるということです。

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

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

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

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

オプション 3

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

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

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

ツイッター事件

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

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

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

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

私の結論と推奨事項

オプション 3!。

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

于 2012-06-08T09:15:42.337 に答える
28

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 つ壊したりすることはできません。これは、ゆっくり動く必要があるという意味ではありませんが、一度に 2 つのことを機能させる必要があることを意味します。API または新しいフィールドへの追加は問題ありませんが、バージョン管理なしで変更/削除を行うべきではありません。

デメリットは今のところ思いつきません。

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

PS また、API をリリースする前に、API を完全に文書化することをお勧めします。Gaug.es API を文書化するプロセスは、私たちの改善に本当に役立ちました

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

于 2012-06-12T01:03:00.990 に答える
10

私は#2と#3のルートに行くことを好みます。主な理由は、#1 が関心の分離に違反し、あらゆる種類のものを混ぜ合わせているためです。最終的には、一致する HTML ページなどを持たない API エンドポイントが必要であることがわかり、同じコード ベースに HTML と JSON エンドポイントが混在することになります。MVP であっても、非常に面倒なので、最終的には書き直す必要があります。

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

3 番目のオプションにも有効な魅力があります。これは、パレートの原則 (80/20 ルール) に従い、メインのマークアップの 20% (またはその逆) をサーバーでレンダリングし、残りの部分を素敵な JS クライアント (バックボーン/etc) で実行する場所です。 . JS クライアントを介して REST API と 100% 通信しているわけではありませんが、必要に応じてユーザー エクスペリエンスを向上させるために何らかの作業を行っています。

これは「依存する」種類の問題の 1 つだと思います。答えは、何をしているのか、誰にサービスを提供しているのか、どのような経験をしてもらいたいのかによって「依存する」ということです。2つまたは3つ、またはそれらのハイブリッドのいずれかを決定できると思います。

于 2012-06-07T23:53:03.157 に答える
7

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

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

于 2012-06-08T10:28:44.583 に答える
7

＃3の次のバリアントを使用します。JSONのみのRESTAPIサーバーを作成します。HTMLWebサイトサーバーを作成します。HTML Webサーバーは、バリアントのように、RESTAPIサーバーのクライアントではありません。代わりに、2つはピアです。表面からそれほど遠くないところに、2つのサーバーが必要とする機能を提供する内部APIがあります。

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

于 2012-06-08T00:10:59.707 に答える
7

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

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

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

于 2012-06-21T13:16:58.837 に答える
6

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

私たちはさまざまな理由でこのアプローチを選択しましたが、まだ大規模に証明されていないことを考えると、少し危険であることは十分承知しています. すべて同じです。これまでのところ、すべてが順調に進んでいます。

これまでは 1 つの API だけで作業してきましたが、プロジェクトの次の段階では 2 つ目の API を使用する予定です。1 つ目は大量のデータ用で、2 つ目は API を介して CMS のように機能します。

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

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

ここであなたの選択を頑張ってください。他の人が共有するものも見てみたい。

于 2012-06-07T23:57:31.703 に答える
4

私のウェブサイトが私のデータの 100% CRUD 実装にならない場合、私は #3 が好きです。これはまだ起こっていません。

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

私はそれについて心配する必要はなく、必要に応じてユーザー側から永続化レイヤーのクエリを実行するだけです。完全な分離を作成することにはあまり関心がありません。これらは通常、異なる目的を果たすことになるからです。

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

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

于 2012-06-08T01:47:04.250 に答える
1

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の開発を進めています。これにより、JavaScript Ember ロジックをサーバー側 (具体的には node.js) で実行し、事前にレンダリングされたアプリケーションの HTML (通常はブラウザーで実行される) をユーザーに送信できます。ページが表示されるまでそれほど長く待たないため、SEO とユーザー エクスペリエンスに最適です。

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

Express 経由ですべてを提供するのではなく、画像と JavaScript を多用するクライアントの提供に nginx を使用することにしました。私の場合、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 を実行する例と、それを使用する多くのクライアントの例がたくさんあります。

于 2015-09-27T14:25:27.127 に答える
1

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

API の負荷やトラフィック パターンなどを予測するのは難しい場合があり、API を個別に提供しているお客様は、プロビジョニングとスケーリングが容易です。人間の Web アクセス パターンに取り込まれてそれを行う必要がある場合は、それほど簡単ではありません。また、API の使用は Web クライアントよりもはるかに高速にスケールアップする可能性があり、どこに努力を向けるべきかがわかります。

#2 #3 の間は、あなたの目標に大きく依存します - #2 はおそらく webapps の未来であることに同意します。

于 2012-06-08T11:13:45.247 に答える
0

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

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

テストが問題です。今、私はJSON データを Rack::Test POST test に渡そうとしています。

于 2013-09-10T10:30:48.167 に答える
0

Rails で JSON API を構築することは最優先事項です。JSONAPI::Resources gem は、http://jsonapi.org 仕様のAPIの面倒な作業を行います。

于 2017-01-07T17:29:31.643 に答える