リソースはコレクション内で同じ構造でなければならない

Question

GET /task/IDでリソースを表示し、コレクションGET /taskで行を表示すると、RESTのサブセットに関する質問が見つかりました。 REST - Resource and Collection Representations

私はApigilityを使用しています。

RESTは公式ではありませんが、全体的なベストプラクティス/標準でできる限り厳格に保持することを望みます。

他のフィールドをコレクションとリソースに含めることはできますか。ソースの部分は同じですが、コレクションのために私はフィルタリングのためのいくつかの余分な情報を必要とし、リソースには今それらが必要です。

これは何らかのルールを破りますか？

Answer 1

シングルトンエンドポイントが要求されたときに完全な表現が返されるのに対して、RESTコレクションレスポンスではリソースの部分表現を返すのは珍しいことではありません。

たとえば、here（私がthis search on Googleで見つけた最初のリンクの1つ、もっと多くあります）を読んでください。

「メンバー」のようなコレクションを、取得コレクション

の取得、）、リンクのリストとして）各リソースの部分的な表現を
2のリソースのリスト全体を
1を返すことがありまたは
3）コレクション内のすべてのリソースの完全な表現。

は、だから、コレクション内のリソース表現がシングルトン表現と異なっていることも珍しくありませんが、私はあなたがむしろ少ないし、より多くのデータを持っているでしょうと言うでしょう。

あなたのコレクションの返信にどのようなフィールドを追加したいと考えていましたか？あなたは例を挙げることができますか？

Answer 2

これは確かに珍しいことですが、一貫性がある方が良いでしょう。なぜ同じものに対して2つのモデルがあるのでしょうか？ Richardson Maturity Model level 1を見ると、サービスエンドポイントが（単一の）リソースにマップされると予想されます。そして、あなたはフィルタリングのために余分な情報をどういう意味ですか？

それは頻繁にシナリオだ場合、あなたはそのようなテンプレートのURI（クエリ文字列）を介してサーバー上でそれを処理することがあります：

GET /task?type={type}&property2={value2}

はそうしないと、あなたはそれらすべてを取得し、フィルタリングを行うことができますクライアントでは（その場合は必ずそのプロパティが必要です）。