REST Api関連およびネストされたリソースのエンドポイントデザイン

Question

私はREST APIを作成しています。たとえば、著者と投稿があります。

だから私は、と著者によって公開記事を取得することができます：

/authors/123/posts 

それとも

/posts?authorId=123 

が、私は柔軟なAPIを構築することは、より良い選択肢かもしれないと思います。著者の記事を取得するには、私はどうなる：だからこのケースでは、私が作成した日付でソートして公開され、また、各ポストのタグやカテゴリを取得しているauthorId = 123からのすべての投稿を取得しています

/posts?authorId=123&published=true&sort=created&expand=tags,category 

。

基本的には、各データベーステーブルにマップされる種類のクエリ言語を作成します。私は特定のエンドポイントを作成する一般的なクエリのためのその後

：

/posts/recent 

が...独立作者の

を最近の投稿を返すだろう、私は多くのレベルを使用しているとき/authors/123/postsが複雑になるかもしれないと思います。

あなたはどう思いますか？

UPDATE

いくつかの答えの後、私の考えは以下の通りです：そこ場合

GET /posts?authorId=123&published=true 
POST /posts 
PUT /posts 
DELETE /posts/123 

：投稿と著者は私が（記事のための一例）を持っているでしょう2つのリソースです

投稿者と著者の間に階層的な依存関係があり、投稿者の投稿が必要な場合があります。

GET /authors/123/posts&published=true 

ポストは、リソース著者の外に存在しません場合は、2つの以前のオプションはに置き換えられます：あなたはどう思います

GET /authors/123/posts?published=true 
POST /authors/123/posts 
PUT /authors/123/posts 
DELETE /authors/123/posts/123 

？

Answer 1

myth各リソースには1つのパスが必要です。どちらの例も正しいです。

/authors/123/posts：あなたの最初の例では

。

階層関係が2つの間にある場合は、現在のコンテキストがauthorであれば、その著者の投稿には問題ありません。

/posts?authorId=123&published=true&sort=created&expand=tags,category：あなたの第二の例では

。

多くのファセットに投稿された投稿のリポジトリ全体をクエリすると意味があります。たとえば、アプリケーションでは、記事を検索するための検索ページがあるかもしれませんが、それはそのための最適なケースです。

モデルビューについて言えば、私たちのリソースはモデルのようなものです、私たちのURLはビューのようです。同じモデルに対して多くのビューを使用することを止めるものはありません。保存されたデータにアクセスするために同じバッキングコードを使用するだけで十分です。あなたのデータを見るためのさまざまな方法（ビュー）があります。

概要：プロジェクトで両方のURLを使用できます。たとえば、著者ページの/authors/123/postsを使用して投稿者の投稿を一覧表示し、投稿検索ページに/posts?authorId=123&published=true&sort=created&expand=tags,categoryを使用します。

あなたが同様の意見については、この記事を見ても持つことができ：What are best practices for REST nested resources

Answer 2

私たちがプロジェクトで使用した経験則：URLパスを使用します。 /authors/123/posts 2つの間に明確な階層関係がある場合は、訪問しているリソースは他のリソースのコンテキスト外では使用できません。たとえば、注文行を取得するときは、/orders/123/linesを使用するのが簡単です。これは、注文行が注文自体のコンテキスト外で意味を持たないためです。

あなたの場合、投稿は投稿者の文脈の外ではっきりと「生きる」ことができます。著者、日付、件名で投稿を検索できる場合は、これらの値をクエリ文字列として渡すのが理にかなっています。だから私の意見では、/posts?authorId=123はここに行く方法です。