2017-09-29 11 views
0

私はいくつかのアイデアを探しています。次のRESTインターフェイスを設計する方法についての提案です。 ここでは、すべてのチームで構成された1つのテーブルを持つデータベースがあると仮定します。次に、私は名前のような属性を持つ人のテーブルを持っています。その間に私は人とチームをつなぐリンクテーブルを持ち、その逆もあります。この表では、その人がチーム(攻撃者のような)に持つ役割についての情報も持っています。だから、人はチームに所属しているときに選手になる。リレーションシップを持つRESTインターフェイスリソース

このための適切なRESTリソース設計は何ですか? 私はリソース/チームを持っていると言います。また、リソース/人。特定の関係を呼び出すためのリソースパスをどのように設計するのですか(リンクテーブルに記載されています)。

ありがとうございました。

+0

まず、ストレージの実装を開始し、次にそれを公開する方法を尋ねます。これは後方です。あなたはクライアントにデータをどのように認識させたいのか自分に尋ねるべきです。それに応じてリソースを設計し、実装されたURIマッピングを思いついてください。それは、実装の決定を前にすべきではないと言っているわけではありません。たとえば、あなたが記述した方法は、n:m関係の正しいデータベース実装です。しかし、あなたは、クライアントが世界をどのように見ているかを運転させてはいけません。これは、RESTfulなAPI設計については難しいことです! –

答えて

0

アソシエーションモデルも公開しても問題ありません。

あなたは/teams/personsに加えてmembershipsを持つことができます(どうして/peopleでも私は逃げません)。これは、クライアントがメンバーシップを操作する場合、特にメンバーシップ自体が関心事である場合、良い練習です。メンバーシップには、開始日や終了日などの属性、「目的」フィールドなどが含まれることがあります。

には、このルートになるがありません。 POSTのように/ teams/someteamにpersonのような作業を行い、チームにネストされた人のリストを表示することができます。同様に、/ persons/arjanにteamをPOSTし、その人のURLにチームのネストリストを含めることができます。このようにして、メンバシップを実装の詳細として扱い、それらをAPIに公開しません。メンバーシップが重要でない場合は、これを行うことができます。

関連する問題