0

REST サーバーに適切なリソース階層が設定されていますが、混乱を招くユース ケースが 1 つあります。

かなり典型的なプロジェクト/グループのセットアップがあり、プロジェクト内のすべてのグループを参照するのは簡単です。ただし、(すべてのプロジェクトにわたって) 特定のステータスを持つすべてのグループが必要な場合があります。これは、標準のサブリソース階層では明らかに不可能です。

私が見る唯一のクリーンな解決策は、グループをリソースとサブリソースとして同時に持つことです (それらは一意のキーでアドレス指定できるため)。以前、リソースを「エイリアシング」する (同じリソースを 2 つの異なる方法でアドレス指定する) という概念について考えたことがありますが、それを表現する最良の方法はわかりません。

4

1 に答える 1

1

アプリケーションをスケールにとらわれないようにする場合は、基本的なリソースを一意に識別されたエンティティ ( Hellandを参照) と考えて、それらのインデックスを公開できるようにすることをお勧めします。インデックスの最も一般的な形式は、HTTP URI の階層的な性質を使用して、アイテムを含むコレクションです。

GET /groups/
    200 OK
    {"entities": [
        "/groups/1/",
        ...
        "/groups/212/",
        ],
     }

これを「プライマリ インデックス」と呼ぶ場合があります。しかし、他にも多くの可能性があります。

GET /projects/foo/groups/
    200 OK
    {"entities": [
        "/groups/7/",
        "/groups/182/",
        ],
     }

GET /groups/by_status/ACTIVE/
    200 OK
    {"entities": [
        "/groups/13/",
        "/groups/64/",
        ],
     }

ただし、これらの代替インデックスには注意してください。特に、複数のサーバーとキャッシュを混在させた場合は、現実と同期しなくなる傾向があるためです (Helland の論文を読んでください)。これが、上記の出力例がアトミック エンティティ自体のコピーではなく、リンクで構成されている理由です。同じ理由で、同じアトミック エンティティを識別する 2 つの URI は必要ありません。これにより、複数のクライアントが同じデータの複数のコピーを取得するため、データが古くなり、更新が失われます。

エンティティが 2 つの異なる識別子 (数値 ID と一意の名前など) によって真に識別できる場合は、一方を正規として選択し、もう一方をそれにリダイレクトさせます。

GET /groups/by_name/bar/
    303 See Other
    Location: /groups/44/
于 2012-07-07T17:06:49.307 に答える