2

JSON 形式などのデータを取得するための RESTful インターフェイスを公開し、RESTful インターフェイスの呼び出しと Web ユーザーの構築を担当する Javascript ファイルを参照する単一の HTML ページを提供する単一ページの Web アプリケーションについて読んだところです。クライアントの Web ブラウザーで動的にインターフェースします。

Play でこれを実装するには、コントローラーが HTLM ではなく JSON を返すようにコントローラーを実装し、クライアント側でユーザー インターフェイスをレンダリングするための CoffeScript を実装する必要があります。

ここまでは順調ですが、クライアント側で実行する JavaScript コードの量がますます増えるため、この設計が大規模な Web アプリケーションに適しているかどうか疑問に思っています。

私の最初のアイデアは、Play のテンプレート エンジンを使用して Web アプリケーションを実装し、次にモバイル アプリケーションに RESTful なインターフェースを提供することでした。

このトピックをカバーする提案、アイデア、またはドキュメントへのリンクは本当に高く評価されます;-)

4

2 に答える 2

2

Play for Scala ブックには、このトピックに関する章があります。単一のビューをエントリ ポイントとして使用します。それだけです。

大規模なアプリケーションに関しては、これは妥当な懸念事項です。そのためには、特に RequireJS (Play 2.1 に組み込みでサポートされている)などのライブラリを使用することをお勧めします。複雑さを管理するために、アプリをサブモジュールに分割することもできます。クライアント側では、おそらくAngularJSなどのフレームワークも使用する必要があります。

Play に関して言うことはあまりありません。RESTful JSON サービスを公開するための非常に優れたプラットフォームです。JSON ドキュメントを参照し、 ReactiveMongoも確認することをお勧めします。

于 2013-02-22T09:56:30.740 に答える
0

共通のRESTAPIを提供することは問題なく機能するはずです。現在、ブラウザ（バックボーンなど）およびiOSクライアント用のPlay2.0サーバーアプリを使用しています。ブラウザクライアントはPlayアプリから完全に分離されており、独立してデプロイされます。

Playテンプレートのアプローチと比較すると、初期のオーバーヘッドがいくらかあると思いますが、テストなどを行うコントローラーのセットが1つしかないため、作業が楽になります。

考慮すべきいくつかのポイント：

  • クライアント認証。できれば、すべてのクライアントに同じ方法を使用します。
  • ある時点で、帯域幅とリクエスト数を節約するために、クライアントの1つに専用のRESTAPIを導入したい場合があります。たとえば、モバイルランディングスクリーンが典型的な候補です。
  • Webクライアント開発者はコードベースを共有していないため、RESTAPIをより詳細に文書化する必要があります。
于 2013-02-27T11:53:27.077 に答える