1

メイン州にある私の会社が所有するすべての店舗のリストを取得したいとします。概念的には、このリクエストは次のように見ることができます。

/stores?state=Maine (All stores such that the state of the store is Maine)

また

/states/Maine/stores (All of Maine's stores)

どちらがより RESTful で、その理由は? 私の理解では、どちらにも長所と短所があるようです。

編集：

私の元の例には、状態のサブリソースとして店舗を持つことは直感的に理解できないかもしれないという問題があります。そのため、別のより詳細な例を次に示します。ISBN によって、または著者ごとにタイトルによって本をグローバルに識別できるとします (著者が 2 つの名前を付けていないと仮定します)。自分の本も同様です）。したがって、このスキームの下で/books/0-525-94892-9は/authors/Ayn_Rand/books/Atlas Shrugged、同じ本を参照することになります。それで、アイン・ランドのすべての本が欲しいとしたら、私はどうしますGET /books?author=Ayn_RandかGET /authors/Ayn_Rand/books?

4

3 に答える 3

1

あなたが与える両方の例（州/店舗と著者/本）では、後者のスキームを使用します。

これにより、さまざまなリソースを直感的に公開できます。URIは、どのリソースを期待するかを明確にし、混乱するのではなく、「パス」として使用されている制約を表します。?key=value&foo=bar&so=on...

説明させてください...

/authors/

すべての作成者リソースのリストを返します。

/authors/Ayn_Rand/

Ayn Randリソースを返します。これには、Ms。Rand自身に関する情報が含まれている可能性があります。

/authors/Ayn_Rand/books

アイン・ランドの本のリストを返します。これは、「プレーンな」本のリストのように見えるかもしれません。

[
{
    title: 'Atlas Shrugged',
    genre: 'Fiction'
    slug: 'atlas_shrugged'
},
{
    title: 'The Fountainhead',
    genre: 'Fiction',
    slug: 'the_fountainhead'
},
{
    title: 'Capitalism: The Unknown Ideal',
    genre: 'Non-fiction',
    slug: 'capitalism_the_unknown_ideal'
}
]

ハイパーメディアを使用して、ISBNで書籍を厳密に参照することもできます。

...
{
    title: 'Atlas Shrugged',
    genre: 'Fiction',
    location: '/books/0-525-94892-9'
},
...
于 2012-11-29T10:57:54.553 に答える
1

/statesとがシステムのリソースでない限り/states/Maine、最初の例を使用します。

于 2012-11-28T19:04:59.853 に答える
1
どちらがより RESTful で、その理由は?

どちらも同じように RESTful です (ただし、技術的には、REST URI は不透明なので問題ありません)。ユースケースに最も適したものは、リソース階層によって異なります。

あなたの本の例から、他の場所で使用されているその本の正規の識別子であるため、ISBN を使用します。「肩をすくめるア​​トラス」と呼ばれる他の本があるかもしれませんし、「アイン・ランド」と呼ばれる他の著者がいるかもしれませんし、十分に編集されていれば、同じ作品の派生版が名前を変更したり、別の著者をリストしたりするかもしれません. {author-name, book-name}書籍を一意{publication-year}に識別するために、少なくとも 2 つのデータを提供する必要があります。ISBN 番号を使用すると、書籍を識別するために 1 つのデータムのみを使用できます。

のリクエストは/authors/{author-name}/books/{book-name}、レスポンスまたはそれ以上のいずれかを返し、ヘッダー302 Found付きの書籍を返し、レスポンス内のリンクを使用してリソースの ISBN URI を指す場合があります。Content-Location/books/{isbn}rel="canonnical self"

編集
私自身の API から例を提供します: 、および
があります。すべてが最上位のリソースです。サイトは住所のある物理的な場所を表します。通常、連絡先は会社を表しますが、個人や学校などの組織の場合もあります。サイトには連絡先である があります。所有者は、その住所に行くときの看板の名前です。ジョブは最上位のリソースです。ジョブには、、、およびjobscontactssitesownerclientsitesite_owner. ジョブのクライアントは連絡先 (すべての連絡先がクライアントであるとは限りません) であり、ジョブの site_owner はジョブの時点でのサイトの所有者です。また、サイトの所有者ではないクライアントのために仕事をすることもあります (つまり、下請けの仕事)。クライアントが誰であるか、当時の建物の所有者などに関係なく、現場で行われたすべての作業の履歴を保持する必要があります。
したがって、特定のクライアントの現場で行われた作業のジョブリストには、いくつかのURI /contacts/{id}/sites/{id}/jobs、、、/sites/{id}/jobs?client={id}_ /contacts/{id}/jobs?site={id}_/jobs?client={id}&site={id}実際、すべての URI は有効であり、最終的に同じ PHP ファイルに到達し、同じ変数を同じ値に設定して、同じクエリを実行します。一部の URI は、より遠回りのルートを取り、さらにいくつかのinclude呼び出しを行います。
これらの異なる URI をすべて許可する理由は、ユーザーがナビゲーション階層 (リストに到達するためにたどるパスに応じて可変の「ブレッドクラム」) で 1 つまたは 2 つのレベルに「上がる」ことを許可するためです。これにより、返される表現がわずかに変更されます。 ）、データセットはライブであり、見ている可能性が高いものに対して非常に動的であり、HTML の結果はキャッシュできないため、正規の URI を再利用しないというトレードオフは、マイナス面よりも多くの利点を提供します。

すべての要点は次のとおりです。

  • リソースに一意の識別子を 1 つ使用するか、リソースに固有の識別子id(ISBN など) が付いていない場合は作成します ( )。

  • どの URI を選択するかは、API の RESTful 度とは関係ありません

于 2012-11-29T11:32:03.113 に答える