0

同じ RESTful リソース (モデル) が 2 つ以上の異なる方法で別の RESTful リソースに関連付けられている場合、適切な URL パスを見つけるのに苦労しています。

  • 特定のトレーナーに関連付けられたトレーニング セッションのすべてのインスタンスを検索する要求を直感的に表す URL パスを指定します。ここで、TrainingSession モデルには Employee モデルへの関連付けであるtrainer_id があります。
  • 特定の研修生に関連付けられたトレーニング セッションのすべてのインスタンスを検索する要求を直感的に表す URL パスを指定します。ここで、TraineeSession モデルには、Employee モデルへの関連付けでもある trainee_id があります。

URL のパスに「trainees」または「trainers」を含めることは、実際のリソースではないため、正しくないようです (TrainingSession と Employee のみ)。

  • /trainees/1/training_sessions
  • /trainers/1/training_sessions

ただし、「employees」の使用はあいまいすぎて、次のいずれかを意味する可能性があります。

  • /employees/1/training_sessions

これらのルート/パスについて何を提案しますか?またその理由は何ですか?

4

2 に答える 2

2

実際に研修生やトレーナーを利用することは全く間違っていません。

研修生とトレーナーの両方の URL を従業員コントローラー関数にマップし、提供された ID を使用して研修生/トレーナー データを検索できます。なぜそれができなかったのかわかりません。それは単にスマートな URL 誘導です。

研修生とトレーナーに関する情報を別々に保存する必要がある場合は、独自のモデルが必要です。しかし、Trainee id と Trainee id が TrainingSession にあり、従業員 ID に直接マップされていて、Trainee と Trainee について他に何も保存する必要がない場合、前述のアプローチが使用できない理由がわかりません。

編集: 以下は哲学の問題であり、したがって主に議論の余地があります。

REST の原則は API ユーザー向けだと思います。そのため、訓練生リソースとトレーナー リソースが存在し、それを操作できることをユーザーが確認する限り、それは REST です。内部でどのように実装するか、たとえば MVC を使用するかどうかを選択します。良い方法は MVC 原則を使用することですが、原則はガイドラインであり、すべての状況に適用できるゴールデン ルールはありません。仮想リソースの作成は問題なく、独自のモデル/コントローラーにマップする必要はないと思います。

于 2012-10-03T18:12:13.023 に答える
0

トレーニングセッションは別のリソースと見なされ、検索パラメータsearchTypeとemployeeIdに基づいてトレーニングセッションを検索しています。
したがって、@GETオン
/trainingsessions?searchby=trainer&employeeId=xyzはトレーナーのためのセッションを提供する
/trainingsessions?searchby=trainee&employeeId=xyz 必要があり、研修生のためのセッションを提供する必要があります。

于 2012-10-03T18:26:53.457 に答える