RESTful APIでネストされたリソースを使用する場合

ユーザーとリンクの2つのリソースがあります。

ユーザーは複数のリンクを関連付けることができます。次のURIでユーザーに関連付けられたリンクにアクセスできるように、RESTful APIを設計しました。

/users/:id/links

ただし、常にリンクだけのURIが必要です。ユーザーに関係なく、すべてのリンクが必要な場合があります。

このために私は：

/links

これは大丈夫ですか？リンクに2つのURIがありますか？

代わりに、次のようなURIを使用してユーザーのリンクにアクセスする必要があるかどうか疑問に思います。

/links/user/:id または /links/?user=:id

この方法では、リンク用のリソースは1つしかありません。

api rest api-design

— オリバー・ジョセフ・アッシュ
ソース

うーん。これはもっとエレガントに見える：/links/user/:id

— theMarceloR

@theMarceloR：これは、3つのうち、特に明確ではない唯一の例です。リンクまたはユーザーのリソースですか？URIは、実際にはクエリであるため、ネストされたリソースメソッド（/users/:id/links）またはクエリ文字列メソッド（/links/?user=:id）を使用した場合、はるかに曖昧ではありません。/links/user/:id一部のフレームワークでは見栄えが良く、ルーティングが簡単かもしれませんが、実際には非常に混乱しています。

— アーロンノート

いいえ、同じ「もの」（この場合はリンクのリスト）に対して複数のリソースを使用しても問題はありません。

私たちは最近、同じ問題に苦しんでいました。私たちの決定は、ネストしない厳密な所有権がないすべてのリソースを持つことでした。言い換えれば、リンクは以下のようにモデル化されます

/links -- all links
/links/:linkid -- a particular link

次に、リンクコレクションのフィルターはクエリパラメーターとして表されます。したがって、特定のユーザーのリンクを取得するには、次を使用します。

/links?user=/users/:userid

これにより、フィルターを簡単に構成することもできます。

/links?user=/users/10&since=2013-01-01

また、概念的に理解するのは簡単です。アイテムのコレクションがあり、それにフィルターを追加します。

そうは言っても、このアプローチについて他のどのURI命名スキームよりも「RESTful」なものはありません。これは、開発者が理解し、理解しやすい、人間が判読できる簡単な規則です。RESTは、リソース識別子に何を入れてもかまいません。

— ワックスウィング
ソース

「ネストされない厳密な所有権がないすべてのリソース」は、適切なルールのように思えます。本当にありがとう。

— オリバージョセフアッシュ

同じ物理エンティティに対して複数のリソースを持つことには何か問題があると思いますが、実際にはこれはそうではありません。個々のリンクには正規のURL（links /：id）がありますが、上記の各リソースは実際にはフィルターが適用された単一のリソース（/ links）です。また、?user=users/:useridクエリ文字列にあるので、私は奇妙です。ちょうど何が悪いの?userid=:useridですか？

— アーロンノート

@Aaronaught：裸のIDではなくuriに固執する理由は、クライアントがすべてのリソース識別子を平等に扱うことができるようにするためです。つまり、クライアントは、「このユーザーは"/*******"; ここで、*は不透明です。ただし、その同じ識別子を常に使用して、そのリソースを（リンクのように）参照したり、そのリソースの最新バージョンを取得したりすることができます。そのURIの内容は、オリジンサーバーによってのみ理解されます。これは、識別子を変更する必要がある場合、たとえば/realm/:businessid/users/:id、クライアントがまったく変更しないことも意味します。

— SingleNegationElimination

@TokenMacGuy：申し訳ありませんが、コメントの一部がわかりません。間の実用的な違いは何だ/users/:userid/linksとは/links?userid=:userid？どちらの場合も、識別子は変更されず、そのリソースの現在のバージョンを取得し、クライアントはそれらを同じように扱います。これはリソースではなく、クエリであるため、このための正規URLなどはありません。したがって、これらはクエリ構文の2つの異なるタイプにすぎません。また、URL構造が変更された場合にクライアントが変更する必要のない方法についても明確ではありません。301が設定されていない限り、RESTの重大な変更と見なされます。

— アーロンノート

@Aaronaught：あなたの懸念を誤解したかもしれません。/linksクエリインターフェイスをサポートしていると仮定すると、サポートし/links?user=/users/123て/links?userid=123いないクライアントのリソース識別子に対するブラックボックスアプローチが可能になります。後者の場合、クライアントは、/users/123ユーザーIDが何であるか、またはおそらく取得したリソースから取得する方法を理解する必要があります/links/456/user。前者は、クライアントが未変更のURIを使用できることを意味します。/links/.../userがハイパーメディア応答（Location:ヘッダーなど）を提供すると仮定します。

— SingleNegationElimination

私の懸念は：/ users /：userid / linksは「links」を返しますが、user_idが識別されない場合は404を返すはずです。

しかしながら

/ links？userid =：useridは、空のリスト（基本的には200）を返す可能性がありますが、これは実際にはおそらくバグです。そして、かなり可能です。

両方とも機能しますが、ネストにより、後で使用できる追加機能が提供されます。

— リチャード・ブラウン
ソース