私の質問は、個別のモデルを 1 つの REST リソースにマージしても問題ない場合と、これが最終的に設計を扱いにくくすることにつながるかどうかです。
私が映画ストリーミング サービスを持っていて、ユーザーが許可されている映画のジャンルのみを視聴できるとします。これらが次の仮説モデルで表されているとしましょう。
users (id)movie_genres (id, genre_name)users_to_genres_permissions (id, genre_id, user_id)
REST ルート/users /movie_genresを介して公開され、/users_to_genres_permissions
さて、この API のユーザー クライアント (ウェブサイトまたはモバイル アプリを考えてください) として、どのジャンルを取得できるかを調べるために、ジャンルのアクセス許可を取得してから、すべての映画のジャンルを取得します。2 つのネットワーク呼び出し。
ただし、API へのラウンドトリップを複数回行わなければならないのは非効率的であり、さらにクライアントで多数の結合を処理する必要があるという議論がなされる可能性があります。この例は 3 つのリレーションで十分に単純ですが、現実の世界ではもっと長いチェーンを持つことができます。
したがって、2 つのモデルを 1 つに折りたたむことを検討できます。たとえば、映画のジャンルに既に参加している許可を返します。
movie_genres (id, genre_name, authorized_for_current_user)
しかし、問題は、この思考プロセスはかなり遠くまで行くことができるということです. サーバー上ですべての参加を行うことで、クライアントの多くの参加と往復を節約できます。しかし、どの時点で停止しますか？REST リソースではなく、連結された一般的なデータの塊を返すのはどの時点ですか?
線を引く場所を決定するための経験則はありますか?