REST - エンドポイントに要約データを含める必要がありますか？

Question

シンプルモデル：

重みを持っている製品、（混合することができる - オンス、グラム、キログラムなど）をそれらに

RESTエンドポイント多くの製品を持っている

Cagtegories、：

/products - get all products and post to add a new one 

/products/id - delete,update,patch a single product 

/categories/id - delete,update,patch a single category 

/categories - get all categories and post to add a new one 

を

質問は、フロントエンドのクライアントがすべてのカテゴリの商品の総重量のグラフを表示したいということです。すべてのカテゴリとそれぞれの製品の総重量を示す棒グラフまたは円グラフを想像してみてください。あなたは、製品の重量とその対策（オンス、グラムなど）を知っているので

明らかに製品モデルは、「weight_value」と「weight_unit」を有します。カテゴリモデルで

1. 、カテゴリ内のすべての製品の重量を合計する計算フィールドを追加します。

   は、私はこれを解決するための2つの方法を参照してください。合計は、そのカテゴリー（保存されていない）のオンザフライで計算されるため、常に最新の状態です。クライアントが常にすべてのカテゴリを必要とすることに注意してください（たとえば、製品を作成するときにドロップダウンを設定するには、そのカテゴリを選択する必要があります）。チャートを作成するのは簡単です。サーバーからチャートのデータを取得する必要はなく、すでにクライアントにあります。しかし、そのデータを初めて読み込むのは遅いかもしれません。製品が追加された場合にのみ、合計は失効します（全体的な数字にはほとんど変化はなく、とにかく失効した合計は問題ありません）。カテゴリID、名前と総重量：

2. は別のエンドポイントを作成し、すべてのカテゴリに対して返すカテゴリ/合計は、言います。このエンドポイントは、すべてのカテゴリをループし、それぞれの重みを計算し、それぞれの重み付きカテゴリデータセットを返します。

私が（1）に見る問題は、それがその演技者ではないということです。非常にスケーラブルではないことは分かっています。特にカテゴリがたくさんの製品（何百万もの）で終わったときには特にそうですが、これはホビープロジェクトであり、そう心配していません。

（1）の利点は、あなたが常にクライアント上のデータを持っており、グラフのデータを取得するための別の要求を行う必要がないということです。

しかし、（2）の利点は、（今では、独自の専用のエンドポイントの内部にあるので）カテゴリ/ IDへのすべての要求は、潜在的に高価な合計操作を負担しないということです。もちろん、そのエンドポイントは、すべてのカテゴリのすべての製品の重みを計算するために、非常に複雑なデータベースクエリを実行する必要があります（ただし、データベースにその値を渡すのは、データベースのものと同じ方法です）。

I本当にこれはもっと良い方法です。どのようにしてRESTfulな方法（HATEOSは基本的に）に当てはまりますか？

Answer 1

私は、スケーラビリティとベストプラクティスを好む2となるだろう。それは本当に重みの計算にカテゴリが要求され、それが「趣味」プロジェクトですので、あなたが問題であることを予想していなくても、それは利益が最小限であるショートカットを避けるために常に最善ですされるたびに実行するために任意の意味がありません。 （または経験は私に教えてくれました！）。

1を選択すると、1つ少ないエンドポイントと1つの追加コールを設定して合計を取得する必要があることがあります。余分なコールでオーバーヘッドがあまり大きくならないようにして、あまりにも多くの労力を要しません。

1または2のどちらを選択しても、性能をさらに向上させるために、合計のキャッシングを考慮することがあります（必要な精度によっては合理的な時間が必要です）。