WebアプリケーションREST API：データは、クライアントまたはサーバーのUIの要件を満たすように構造化する必要がありますか？
私が取り組んでいるWebアプリの場合、かなり基本的なリレーショナルデータベースがあります。 RESTful APIを介してこのデータベースにアクセスし、データが取得されたらReactでマークアップを生成します。
これらのJSON応答をクライアント側で絶えず操作/処理して、これらのオブジェクトをUIにとってよりフレンドリーな構造に構造化していることに気付いた場合、それはおそらくクライアントでやりすぎている兆候でしょうか？
私は最初は業界で比較的新しいですが、問題のバックエンドに取り組んでいる別の開発者にこれらのことをいつ伝えるべきかを知りたいと思っています。
これはおそらく、REST Web Apps向けのAPI全般についての幅広い質問に漏れる可能性があります。
フロントエンドでのデータフェッチに対する応答は、UIの要件に従ってすでに構造化されていると思いますか、それとも要求しすぎますか？
この良い例は、「製品」ページのカテゴリリストです。製品の全リストをフェッチしてから、そのデータからカテゴリリストを作成するのが理にかなっていますか。それとも、最初にフェッチを開始するときに応答オブジェクトにカテゴリなどのすでに構造化されたリストがあることを期待するべきですか。製品のリスト？
アプローチは、Webアプリがバックエンドアプリケーションの唯一のユーザーであるかどうかによって異なります。また、開発チーム（この場合はあなた自身）がより熟練しているもの（バックエンドまたはフロントエンド開発）にも依存します。
私の好みは、バックエンドアプリでできるだけ多くのロジックを使用し、フロントエンドではできるだけ少なくすることです。これは、私のスキルセットと、バックエンドでビジネスロジックを実装およびテストする方が簡単だという確信（当然、バイアスがある可能性がある）の両方によるものです。
だから私は何をするでしょう：
- フロントエンドがバックエンドアプリの唯一のユーザーである場合は、すべてのAPIを調整して、UIで簡単に使用できるようにし、UIが提供するものにできる限り近いデータを提供します。このようにして、ロジックはほとんどすべてバックエンドにあり（IMOの開発とテストが容易）、フロントエンドは多くのビジネスロジックを扱うことなく、データの表示に集中できます。
- バックエンドアプリにフロントエンド以外のユーザーがいる場合、またはAPIをほとんど制御できない誰かが作成したバックエンドアプリと通信する必要がある場合は、バックエンド用フロントエンド（BfF）を作成することを検討します。 Backend-for-Frontendは、UIと「実際のバックエンド」の間のプロキシとして機能するバックエンドアプリです。このアプリでは、データをバックエンドの形式から、UIですぐに使用できる形式に変換できます。その後、非常にシンプルなフロントエンドアプリとすべてのビジネスロジックをBfFに含めることができます。基本的に、BfFはファサードであり、UIに一致するようにバックエンドアプリのAPIを直接変更できない場合に、前の箇条書きで説明したアプローチを使用できます。
それは、実際にはAPIの対象ユーザーに依存します。公開APIを公開するつもりなら、本当にそれに向けて設計する必要があります。 APIがUIをサポートするために厳密にである場合、そのAPIをアドホックに構築します。
ただし、これは GraphQL および Falcor （または他の同様のもの）の使用法の1つです。 GraphQLは学習曲線が高くなりますが、Webサービス全体で表示する必要がある正確なデータのリクエストをマップできます。パブリックAPIはそのままで、この統一されたクエリ言語を使用して、データの要求を1つに統合できます。通常、GraphQLは一種のAPIプロキシに存在するため、いくつかのインテリジェントなキャッシュが可能です。
学習曲線は非常に高くなりますが、投資により多くの力を得ることができます。コストとニーズを比較検討してください。 APIがかなり単純な場合は、ニーズが実際に複雑になるまで、これを検討するのを遅らせることができます。
APIの主な目的がデータを単一のWebアプリにプッシュすることである場合、APIのメソッドの一部（すべてではない）をWebアプリに合わせて調整できる許容できる構造だと思います。これらの要件がすぐに表示される場合は、後でより一般的な目的で使用できるいくつかの一般的なAPIエンドポイントがあることを確認してください。
アプリケーションのレイヤを必ず宣言することにより、または厳密に
この短い答えがあなたに役立つかどうかはわかりません。通常、私はクライアントUIに従ってデータを構造化せず、十分な情報をクライアントに送り返して、クライアントがUI要件を満たすためのモデルを作成できるようにします。これにより、クライアント側の問題をサーバーから切り離すことができます。また、APIの消費者がWebアプリ、モバイルアプリ、またはデスクトップベースのWPFアプリケーションであるかどうかをサーバーが考える必要があるのもなぜですか。