RESTful APIでネストされたリソースを使用する場合
ユーザーとリンクの2つのリソースがあります。
ユーザーは、いくつかのリンクを関連付けることができます。以下のURIでユーザーに関連付けられたリンクにアクセスできるように、RESTful APIを設計しました。
/users/:id/links
ただし、常にリンクのみのURIが必要です。ユーザーに関係なく、すべてのリンクが必要になる場合があります。
このために私は持っています：
/links
これは大丈夫ですか？リンク用の2つのURIがありますか？
代わりに、次のようなURIを使用してユーザーのリンクに到達する必要があるのかと思います。
/links/user/:idまたは/links/?user=:id
この方法では、リンク用のリソースは1つしかありません。
いいえ、同じ「もの」、この場合はリンクのリストに対して複数のリソースを持つことに問題はありません。
私たちは最近、同じ問題に苦しんでいました。私たちの決定は、ネストされないstrict所有権がないすべてのリソースを用意することでした。言い換えると、リンクは以下でモデル化されます
/links -- all links
/links/:linkid -- a particular link
次に、リンクコレクションのフィルターはクエリパラメーターとして表現されます。したがって、特定のユーザーのリンクを取得するには、次のようにします。
/links?user=/users/:userid
これにより、フィルターを簡単に構成することもできます。
/links?user=/users/10&since=2013-01-01
そして、概念的に理解するのは簡単です-あなたはアイテムのコレクションを持っていて、それにフィルターを追加します。
とはいえ、このアプローチについては、他のどのURI命名方式よりも「RESTful」なものはありません。これは、人間が読める形式であり、開発者が理解して受け入れやすい規則にすぎません。 RESTは、リソース識別子に何を入れてもかまいません。
だから私の懸念は：/ users /：userid/linksは「リンク」を返しますが、user_idが識別されない場合、これは404を返すはずです。
しかしながら
/ links？userid =：useridは、実際にはおそらくバグである空のリスト（基本的には200）を返す可能性があります。そして、かなり可能です。
どちらも機能しますが、入れ子にすることで、後で追加できる機能が追加されます。