ユーザーが音楽祭を管理できるようにする Web サービスがあります。各フェスティバルには場所があり、複数のステージがあり、各ステージには複数のアーティストがいます。
したがって、ツリー構造として表すことができるフェスティバル、場所、ステージ、アーティストの4つのエンティティがあります。これらには単純な CRUD が必要です。
REST API の用語では、4 つの URI (/festivals、/locations、/stages、および /artists、場合によっては /id が後に続く) を実装して、POST、PUT、GET、または DELETE で要求します。
でも、僕にとっては、場所もステージもアーティストも、フェスと関係がなければ興味がない。では、なぜこれらのエンティティに対して CRUD メソッドを実装する必要があるのでしょうか? フェスティバル エンティティのみの CRUD では不十分ですか?
欠点 :
私の API (ウェブサイト、ネイティブ モバイル アプリ、その他のサービスなど) のクライアントは、私のフェスティバルのサブエンティティを読み取ることができません。しかし、前に言ったように、私のサービスのサブエンティティは、所属するフェスティバルなしでは興味がありません。したがって、各クライアントは、フェスティバル、フェスティバル全体、およびすべてのサブエンティティを取得する必要があります。
同じクライアントは、アーティストの名前を変更しただけでも、フェスティバル全体を更新する必要があります。これは最悪の欠点のように思えますが、結局のところ、私のフェスティバルの完全な json (最大数 kb) を、少し短くなる部分的な json の代わりに送信するのは悪いことですか?
利点 ：
- 16 ではなく 4 つのメソッドをコーディング、テスト、および維持する必要があります (この単純なツリー構造を維持すると仮定すると、管理するエンティティがさらにある場合はさらに多くのメソッドが必要になります)。
技術的には、node.js + mongodb の素敵な組み合わせでこれを行います (これは、mongodb のスーパー ツリーに優しい側面であることを除いて、状況とはあまり関係ありません)。
このアプローチについてどう思いますか？このアイデアには他にも欠点がありますか?