メインページ用のREST API - 1つのJSONまたはそれ以上？

Question

（Java Spring）サーバーから自分の（JS）クライアントにRESTful APIを提供しています。 メインサイトのページには、多数の論理ブロック（ニュース、最後のコメント、傾向のあるもの）が含まれ、それぞれに対応するエンティティがサーバー上にあります。 、私は一般的に、それは一つの大きな要求/応答を持っている方が良いでしょう知っている、行く

/api/main_page/ -> 
{ 
    news: {...} 
    comments: {...} 
    ... 
} 

のように一つのリクエストを処理したり、クライアントが

/api/news/ 
/api/comments/ 
... 

のようないくつかの要求をやらせるために右のいずれかどちらの方法でありますこれもこの状況に対する答えですか？

Answer 1

私は一般に、要求されたリソースがシステム状態の一部を反映している場合、複数の要求を正当化できると思います。 （私の個人的な経験則、まだWIPです）。

つまり、newsがクライアントアプリケーションに多く表示される場合は、一度リクエストしてできる限りどこでも再利用します。ここで集約する場合は、あとで要求する必要があります。実際には表示されないものもありますが、集計でnewsの表現が異なり、/news/{id} -resourceの場合は魔法が必要です。 この方法では、ページが初めて読み込まれると通信が増加しますが、実行する時間が長いほど、クライアントアプリケーション全体の通信が減少します。 サーバ上の状態は、クライアントへの要求によってコピーされ、必要に応じて更新されます（Etags、最終変更など）。あなたの例では

はそれが/newsと/commentsが最後の訪問以来最新またはのいくつかの並べ替えているように見えるが、ないすべて。 これが当てはまる場合は、/comments/latestまたはそれに類するもののように、私もそれらをresurceとして設計します。 いずれにしても、彼らには/news/{id}または/comments/{id}への自己リンクしかないでしょう。それでは/comments/latestへのリクエストがありますが、news -self-linkのリストには何の結果も出ていません。もしまだ私がリクエストしていない場合は、news（キャッシュされたコピーがまだ残っているかどうかチェックしたいかもしれません最新の）。

/news/{id}へのリクエストは、実際に表示される場合（スクロール、スワイプ）にのみトリガーすることもできます。

おそらくnewsまたはcommentの寿命がこの質問に答える基準です。クライアントでのキャッシュの意味は、ブックストアアプリのbookとは逆に、システムにとって不可欠ではありません。

Answer 2

理想的には、ページの個々の構成可能なコンテンツブロックを同じAPIからフェッチするために、異なるAPI呼び出しを行う必要があります。

• このように、コンテンツブロックはお互いに疎結合しています。

• あなたは に拡張して（別のフレームワークに）移植し、独立して変更することができます。
  これは、アプリケーションが大きくなると非常に便利です。

• の場合、機能をオフにするのは簡単です。

• この場合、A/Bテストも簡単です。

• 書き込みオートメーションは でも非常に簡単です。

• 全体的にテストの労力を軽減するのに役立ちます。

しかし、実際にこの呼び出しを1回の呼び出しで取得したい場合は、次に、追加のparamsをリクエストに追加し、サーバーがその追加のparamを見ると、BLレイヤーから独自のメソッドを呼び出すことによって、レスポンスに追加の独立したJSONを追加します。

スピードが問題の場合は、しばらくサーバー上でこれらの呼び出しをキャッシュするようにしてください（アプリケーションの種類によって異なります）。