REST APIでリソースと見なされないデータのエンドポイントを設計する方法

Question

ユーザーコンテキスト：

学校管理者がダッシュボードにログインします。ページは、ページの上部にあるデータのブロックが表示されます。

1. 人以上の学生が残した過去の週にわたり
2. 集約フィードバックをサービスを使用し、学生（ポジティブ、ネガティブ、ニュートラル）の数過去1週間のパーセンテージ。

   ：

3. その他の集計データ

の下側には、月別のサービスの利用状況を表すチャートやグラフの束があり、日常的に使うなど

私の問題時間で分解私は、エンドポイントがリソースを定義する必要があるRESTプリンシパルの後にAPIを構築しようとしています。これらのリソースを処理するアクションとしてHTTP動詞を定義する必要があります。私の問題は、実際に私のリソースのどこにも収まらないような、より多くの「分析的」な集計データのエンドポイントを構築することです。理想的には、各グラフまたはチャートは1つのエンドポイントへの要求であり、上位の集約データのブロックは3つの要求（データごとに1つ）ではなく、独自の要求になります。これらの特定のシナリオのエンドポイントを構築する方法について、正しい方向で私を導く人はいますか？

おかげ

Answer 1

誰かがこれらの特定のシナリオのためのエンドポイントの構築については移動する方法については正しい方向に私を導くことはできますか？

TL; DR：これらのシナリオをサポートするために、ウェブサイトをどのように構築しますか？それを行う。

ドキュメントストアのようなものを使用していた場合は、URI、たとえば/feedbackReports/lastWeekをキーとして使用して、そのレポートの表現をドキュメントストアから取り出してクライアントに返しますさまざまなビットのメタデータとともに）。

ファイルシステムのようなものを使用していた場合は、URIを取得して/www_root/feedbackReports/lastWeekのようなファイルへの参照を作成し、そのレポートの表現をディスクから読み取ってクライアントに返しますさまざまなビットのメタデータで）。

あなたはリレーショナルデータベースのようなものを使っていましたが、URIを取って「先週」のレポートが要求されていることを確認してから、「-7日」のパラメータプリペアドステートメントに変換して実行し、メモリ内のデータをそのレポートの表現に再構成して、それを（さまざまなメタデータとともに）クライアントに返します。

私は、エンドポイントは、これらのリソース上で実行するアクションとして、リソースおよびHTTP動詞を定義する必要がどこRESTの原則を以下のAPIを構築しようとしているが

問題のRESTの原則は、そのAPIの分離株でありますすべての実装の詳細からクライアント（および中間コンポーネント） APIは、アプリケーションが着用するマスクであり、Webインテグレーションだけが機能します。

私の問題は、実際に私のリソースのどこにも収まらないような、この「分析的」な集計データのエンドポイントを構築することです。

これ以上のリソースを作成してください。

注：これらは統合リソースです。つまり、Webクライアントがあなたのドメインと対話する必要がある表現を生成します。

Jim Webber, in 2008

URIs do NOT map onto domain objects - that violates encapsulation. 
Work (ex: issuing commands to the domain model) is a side effect of 
managing resources. In other words, the resources are part of the 
anti-corruption layer. You should expect to have many many more 
resources in your integration domain than you do business objects 
in your business domain.