RESTリソースが単数または複数であることは妥当ですか？

次のような従来のレイアウトではなく、私は疑問に思っています。

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

たとえば、単数形と複数形の方が便利でしょう。

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

したがって、製品のコレクションを作成するには、次のようにします。

POST api/Products {data: filters} // returns api/Products/<id>

そして、それを参照するには、次のようにします。

GET api/Products/<id> // returns array of products

私の意見では、このように処理することの主な利点は、製品のコレクションを簡単にキャッシュできることです。たとえば、製品のコレクションに1時間のライフタイムを設定すると、サーバーへの呼び出しが大幅に削減されます。もちろん、私は現在、このように物事を行うことの良い面しか見ていません。欠点は何ですか？

多くの場合、コレクションがAPIとやり取りする最も便利な方法になると、単一のメンバーを1つだけのコレクションと考える方が簡単な場合があります。その後、後でシングルとやり取りするためのAPIを公開したい場合は、渡されたシングルをそのメンバーを含むコレクションに変換し、他のAPIの同じ実装を使用する必要があります。

ここで私が言っているのは、コレクションを相互作用メカニズムにしたい場合は、コレクションのみのAPIから始めて、システムが完成した後、他のAPIがインターフェースレイヤーでの単純な付属品であり、その後特に便利です。ただし、YAGNIを適用し、必要なシングルのいくつかのインスタンスに対してコレクションインターフェイスを使用するだけの場合、その有用性は最小限であることに気付く場合があります。

欠点は、呼び出し側のプログラムもリソース名を複数形にする必要があることです。これは、組み込みの複数形化メカニズムを持たないクライアント言語ではトリッキーになる可能性があります。単一のままにしておくと、呼び出し元がクライアントライブラリのコード生成を自動化しやすくなります。

これを軽減したい場合は、RESTサービスのSDKを自分で生成できます。または、あなたはただ意見を述べられ、不満を処理することができます:)