このバックエンドは、アドホックフロントエンドアプリケーションで消費されます。しかし、他のシステムでも統合され、APIを公開する予定です。独自のWebアプリと他のシステムの両方でAPIデザインパターンを統合する
残りの部分を設計するときには、他の多くのテーブルを結合できる1つのデータベーステーブル（テーブルAと呼んでいます）があります。
私の戦略は、私たちが持っているアドホックフロントエンドに従った "理由"のあるバックエンドにルートを構築することです。
したがって、テーブルAから行を取得する必要があるフロントエンドにページがある場合（このページを呼び出す）、3つの他の結合テーブルを作成する場合は、バックエンドはたぶん "page1"と呼ばれ、テーブルAから、そして他の3つのテーブルからも行を返します。
これはもちろんバックエンドを構築する通常の方法です。しかし、それが他のシステムでも使われるようになると、誰かがこれらのシステムが "page1"というルートを必要としないかもしれないと主張できます。彼らのフロントエンドはおそらく "ページ1"を構築することはありません。
だから、ここの人たちによれば、もっと珍しいことにAPIを構築する方が良いでしょう。ルート "page1"を作成する代わりに、 "hateoas"に従ってそれを構築する必要があります。その原則を理解すれば、私のアドホックフロントエンドにリソース "page1"を要求させる代わりに、 "pageForTableA"を要求します。そして、リソース "pageForTableA"は、結合される可能性のあるテーブルがどれであるかを返すべきです。
この場合、私のフロントエンドのページ1では、バックエンドに "page1"リソースがある場合、私はしたいようなものではなく、サーバーへの4回のリクエストを行う必要があります。
あなたはどう思いますか？
私はまた、戦略を参照してください。このパターンの名前があるかどうかは分かりませんが、このようになります。
テーブルAから行だけを返すバックエンドのリソースですが、ルートにも引数があります。引数は、他のすべてのテーブルの名前を含む配列です。
フロントエンドが呼び出したのであれば：
getTableA(array('tableB', 'tableD', 'tableF'))
を次にリソースは、一言で言えば、テーブルB、D及びFに参加/含まれます：APIリソースは、フロントエンドは、それが配信を取得したいのかを決めましょう。
あなたはこれらの3つの戦略のどれを考えていると思いますか？それとも考慮に入れることができるものがいくつかありますか？