web-dev-qa-db-ja.com

Restful Uriを使用した多対多の関係の処理

開発中のアプリケーションにデータベースリレーションとRestful URIを選択するときに混乱しています。

以下の要件を備えたシンプルなライブラリアプリケーションを作成しています。

  1. 本は多くのカテゴリに属する​​ことができます。例えば、物理学の本は教科書と科学のカテゴリに属します。本には多くのカテゴリ/ラベル/タグがあると言えます。
  2. 1つのカテゴリの書籍を表示します。
  3. 本のすべてのカテゴリを表示します。
  4. カテゴリまたは本の情報を使用して本を検索します。
  5. CRUD操作の予約
  6. CRUD操作のラベル付け

これらすべての要件を考慮して、私はManyToMany BooksとLabelsの間の関係を選択します。 Hibernate Frameworkを使用して実装しました。このためにRestful Servicesを設計することになると、非常に混乱します。テーブル関係の選択にも疑問を投げかけます。

安らかなうりはまだ作った。

/ books

/ books/{bookid}

/ labels

/ labels/{labelid}

しかし、本に対するラベルのリスト、またはラベルに対する本のリストを取得したい場合。 Restful URIを使用してそれらをマップする方法。私はこれを考えることができます

/ book/{bookid}/labels

しかし、これを考慮して、1つのラベルに対して本のリストを取得することをマッピングする方法

テーブルリレーションシップの選択が正しいかどうか、そして正しい場合は、それに対して安静なuriを設計する方法を知りたいです。いいえの場合は、私を訂正して、このシナリオに光を当ててください。ありがとう

database-designrestweb-services
5
Saif ullah Minhas

表について言えば、1つの本に多くのラベルと1つのラベルに多数の本（かなり妥当な音）を付けることができる場合、それは多対多の関係です。

RESTの場合、リソースについて話し、URIが一意識別子であるため、多対多の関係は実際には少し混乱します2つの方向から1つの同じリソースにアクセスします。

おそらく最良の方法は、リソースを単純なもの（本、ラベル）だけでなく、特定のセット（本、本のラベル）としても見ることです。とにかくリソースを入れ子にしている場合が多く、多対多は1つのバリアントであり、これらのセットを表示する2つの異なる方法が理にかなっています（ユーザーが両方のバリアントでアクセスすることを想定しているため、ユースケースとして考えられます）。

したがって、実際には次の2つの方法でアクセスできます。

/book/{book_id}/labels

そして

/label/{label_id}/books

著者のような他のリソース（著者は多くの本を書いており、多くの場合、1人の本で十分に多くの著者が共同で作業している可能性があります）や出版社でさえ、同様のアプローチを取るでしょう。カテゴリーも多対多だと思います。

Sombodyが上記のURI（/ book/{book_id}/labels）から単一のラベルを選択した場合、（/ book/{book_id }/label/{label_id}）。

したがって、ルートをできるだけ浅くして、ネストしすぎないようにしてください。しかし、類似のもののリストに対して異なる見方をすることを禁止するものは何もありません。

4
thorsten müller