1

データを集約するための柔軟な Web サービスを設計しています。

売上を例にとると。販売リソースには次のプロパティがあります。

  • 営業担当者
  • 製品
  • 価格
  • お客様
  • ID
  • デパートメント
  • 日にち
  • 等

したがって、sales にアクセスするための基本的な URI は次のようになります。

api/sales/{id}

次の要件を満たすように URI を設計する必要があります。

  1. 部門の総販売数
  2. 一人当たりの商品の累計販売数
  3. 月

だから、3つの基本的な要件。結果のグループ化、フィルタリング、および選択 (GROUP BY、WHERE、および SELECT に類似)。

URI の設計方法 私にとっての本当の問題は、グループ化をどのように設計するかです。ここに私が検討しているいくつかのアイデアがあります：

  1. 現在の URI 設計を維持しますが、追加のパラメーターを追加します。

    例えば

    /api/sales?groupby=department&groupby=customer

  2. 新しい URI:

    /api/sales-aggregator?groupby=department&groupby=customer

  3. パスの一部としてグループ化を含める:

    /api/sales-aggregator/department/customer

    ただし、部門と顧客の順序は任意です。

  4. 代替パス ソリューション

    /api/sales-aggregator;groupby=部門、groupby=顧客

おすすめは？

4

1 に答える 1

0

3または4を少し変更して使用します。

GROUP BY ステートメントは、集計関数と組み合わせて使用​​され、結果セットを 1 つ以上の列でグループ化します。

SQL GROUP BY 構文

SELECT column_name, aggregate_function(column_name)
FROM table_name
WHERE column_name operator value
GROUP BY column_name;

一般的なものが必要な場合は、さまざまな解決策があるため、このaggregator単語を使用しても問題ありません。aggregationGETで使いたいなら、もっといい言葉だと思います。POST では を使用しても問題ありませんaggregator。

リンクが一般的な目的を満たす必要がない場合はaggregation、集計関数の結果またはクエリ (複数の集計関数を使用する場合) を説明する特定の名前に名前を変更する必要があります。たとえば、GET /api/sales-person:123/sales-countまたはGET /api/sales-count?sales-person=123.

集計関数で使用される集計と項目を 1 つの応答で返す別のオプション。

GET /api/sales/?sales-person=123 -> 200 ok
{
    count: 123,
    total: {
        value: 1234567,
        currency: "USD"
    },
    sales: [
        {
            id: 1,
            price: {value: 34556, currency: "USD"},
            ...
            links: {self: {href: "/api/sales/1"}}
        },
        ...
    ]
}

表現で集計、アイテムのプロパティなどを有効/無効にする場合は、設定ヘッダーでこれを使用できます。(これを使用する場合は、 vary ヘッダーに優先を追加することを忘れないでください。そうしないと、キャッシュ制御が適切に機能しません。)

于 2015-11-30T12:46:02.700 に答える