1

REST エンドポイントの設計方法について議論しています。基本的に、この不自然な例に行き着きます。

私たちが持っているとしましょう：

/netflix/movie/1/actors <- returns actors A, B and C
/netflix/movie/2/actors  <- returns actors A, D, and E

アクター A は同じアクターです。

「より良い」俳優の伝記を取得するには（はい、判断の呼びかけです）：

/netflix/movie/1/actors/A
/netflix/movie/2/actors/A

また：

/actors/A

最終的に意見の相違は、特定の階層を期待する Ember.js を使用することと、同じデータに複数の方法でアクセスしたくないことから生じています (最終的には、実際には少量のコードの重複になります)。/actors/A を使用するように Ember.js をマップすることは可能であるため、厳密な技術的制限はありません。これは実際には哲学的な問題です。

私は周りを見回しましたが、この種のことについて確かなアドバイスを見つけることができません.

4

3 に答える 3

4

私は同じ問題に直面し、単純さと健全性 (ルートごとに1 つのタイプのリソース) のために、オプション 2 (リソースごとに 1 つの「標準的な」URI) を選択しました。

それ以外の場合は、いつ停止しますか? 検討：

/actors/
/actors/A
/actors/A/movies
/actors/A/movies/1
/actors/A/movies/1/actors
/actors/A/movies/1/actors/B
...
于 2013-06-04T20:06:35.360 に答える
3

私は部外者の観点から、movies/1/actor/A がその映画のその俳優に固有の情報を返すことを期待しますが、/actors/A はその俳優に関する一般的な情報を返すことを期待します。

類推すると、projects/1/tasks/1/comments がタスクに固有のコメント (URL を介した関係の最高レベル) を返すことを期待します。

projects/1/comments が下位レベルのプロジェクトに関連するコメントを返すか、プロジェクトからのすべてのコメントを集約することを期待します。

この類推は問題のデータに固有のものではありませんが、返されるデータに関する特定の期待につながる URL 階層のポイントを示していると思います。

于 2013-06-04T20:05:27.263 に答える
3

この場合、私は明らかに/actors/A.

私の推論は、/movie/1/actorsリストを報告するということです。このリストは、映画と俳優の間の1-n マッピングであり、さらにノードを含むパスとは見なされません。映画ツリーで俳優を見つけることは期待できません。

いつか/actors/A/movies1 と 2 を返す実装を実装するかもしれません。これにより、次のような URL を実装することになり/actors/A/movies/2ます。

オブジェクトごとに 1 つの URL を使用し、1-n マッピングを見つけることができる 1 つの明確な場所を希望します。

于 2013-06-04T20:05:59.080 に答える