WebアプリケーションREST API:データは、クライアントまたはサーバー上のUIの要件を満たすように構成する必要がありますか?

私が取り組んでいるWebアプリには、かなり基本的なリレーショナルデータベースがあります。 RESTful APIを介してこのデータベースにアクセスし、データが取得されたらReactでマークアップを生成します。

これらのオブジェクトを自分のUIにとってよりわかりやすい構造に構造化するためだけに、クライアント側でこれらのJSON応答を絶えず操作/処理しているのであれば、おそらく私はクライアントでやり過ぎているという兆候ですか?

私は最初は業界で比較的新しいですし、問題のバックエンドに取り組んでいる可能性がある別の開発者にいつこれらのことを引き継ぐべきかを知ることにもっと関心があります。

これはおそらく、Webアプリケーション用のREST API全般についてのより広範な質問になる可能性があります。

フロントエンドでのデータフェッチに対する応答は、UIの要件に従ってすでに構造化されていると思いますか、それともあまりにも多くを求めていますか

この良い例は、「商品」ページのカテゴリリストです。商品の全リストを取得してからそのデータからカテゴリリストを作成するのは妥当なのでしょうか。製品リスト?

3
nl ru de

4 答え

それは本当にあなたのAPIの対象読者によります。もしあなたがパブリックAPIを公開しようとしているなら、あなたは本当にそれに向かって設計する必要があります。 APIがUIをサポートするために厳密にされている場合は、アドホックに構築してみましょう。

ただし、これは GraphQL および Falcor (またはそれに似た人)。 GraphQLにはより高い学習曲線がありますが、Webサービス全体に表示する必要がある正確なデータに対する要求をマッピングすることができます。あなたの公開APIはそのままで、データに対するリクエストを一つに統合するためのこの統一されたクエリ言語を持っています。 GraphQLは通常、ある種のAPIプロキシー内にあるので、インテリジェントなキャッシングが可能になります。

それは高い学習曲線で来ます、しかしあなたはあなたの投資のために多くの力を得ます。あなたの必要性に対して費用を量りなさい。あなたのAPIが非常に単純な場合、あなたのニーズが本当に複雑になるまでこれを見るのを遅らせることができます。

3
追加された

あなたのアプローチは、Webアプリケーションがバックエンドアプリケーションの唯一のユーザーであるかどうかによって異なります。それはまたあなたの開発チーム(この場合あなた自身)がより熟練しているものに依存するかもしれません:バックエンドまたはフロントエンド開発。

私の好みは、バックエンドアプリケーションではできるだけ多くのロジックを、フロントエンドではできるだけ少ないロジックを使用することです。これは私のスキルセットと、ビジネスロジックがバックエンドで実装およびテストするのが簡単であるという確信の両方によるものです(もちろんバイアスされることもあります)。

だから私は何をするだろう:

  • フロントエンドがバックエンドアプリケーションの唯一のユーザーである場合は、すべてのAPIをUIで使いやすくなるように調整し、できるだけUIに表示されるものに合うようにデータを提供します。このように、あなたのロジックはほとんどバックエンドにあり(IMOの開発とテストがより簡単です)、フロントエンドは多くのビジネスロジックを扱うことなく単にデータを提示することに集中することができます。
  • バックエンドアプリにフロントエンド以外のユーザーがいる場合、またはAPIをほとんど制御できない場所で誰かが書いたバックエンドアプリと通信する必要がある場合は、Backend-for-Frontend(BfF)を書くことを検討します。 Backend-for-Frontendは、UIと「本物のバックエンド」の間のプロキシとして機能するバックエンドアプリです。このアプリでは、バックエンドのフォーマットからUIで使用する準備ができているフォーマットにデータを変換することができます。そうすれば、非常に単純なフロントエンドアプリと、BfF内のすべてのビジネスロジックを作成できます。基本的に、BfFは、UIに合わせてバックエンドアプリのAPIを直接変更できない場合に、前の箇条書きで説明した方法を使用できるファサードです。
2
追加された
@connected_userこれは興味深い問題です。ある意味では、これらは似ていますが、「実際のバックエンド」サービスがデータ層として機能すると想定した場合に限ります。ほとんどの場合、これらのサービスには独自の何らかのビジネスロジックが含まれているため、これは通常正しくありません。
追加された 著者 David Perlman,
私はあなたのフロントエンドのフロントエンドのコンセプトが本当に好きです!
追加された 著者 Graham,
あなたのBfFの概念は、「3層アーキテクチャ」と同義語ですか?
追加された 著者 doweio,

APIの主な目的がデータを単一のWebアプリケーションにプッシュすることである場合、私はその受け入れ可能な構造であるが(すべてではない)APIのメソッドのいくつかはWebアプリケーションに合わせて調整されると思います。これらの要件がすぐに明らかになった場合は、後でより一般的な目的に使用できる一般的なAPIエンドポイントがいくつかあることを確認してください。

私たちは自分のアプリケーションのレイヤを宣言することによって、あるいは厳密には必要以上に多くの仕事を自分自身に与えることがあると思います。

1
追加された
ソフトウェアの他の多くの機能と同様に、アプリケーション内のさまざまな要因によって変化する可能性があるため、実際には「理想的」とは言えません。それらが大きく変わる可能性がある場合は、サービスをより汎用的なものにしておくことをお勧めします。ただし、1つのリクエスト内でホームページのすべてのデータを処理する方法をAPIが知っている場合は、サービスの汎用性と得られるクエリパフォーマンスのバランスを取る必要があります。あなたは最善の策は、突き刺して、あなたの決定がアプリへの次のラウンドの変更によってどのように影響されるかを見ることです。
追加された 著者 Graham,
同意する。しかし私の場合、データをUIに優しいオブジェクト構造に処理することはとにかく起こります。フロントエンドで発生するのか、フロントエンドで到着する前に発生すると予想されるのか、混乱していると思います。したがって、フロントエンドのコンポーネントはマークアップのレンダリングなどを厳密に担当する必要があります。フロントエンドコンポーネントのみが関係する方法でデータを構造化する一般的な方法は、マークアップをレンダリングすることです(できるだけ処理を最小限に抑える)。 Webアプリのこのような状況での「理想」は何ですか?
追加された 著者 doweio,

この短い答えがあなたに役立つかどうか私にはわかりません。通常、私はクライアントUIごとにデータを構造化しないで、クライアントに十分な情報を送り返し、クライアントがUI要件を満たすために特別にモデルを作成できるようにします。これは私がクライアントサイドの懸念をサーバーから切り離しておくのを助けます。また、なぜサーバーはapiの利用者がWebアプリ、モバイルアプリ、さらにはデスクトップベースのwpfアプリケーションであるかどうかさえ考えなければならないのです。

0
追加された
サンプルを使って具体的な例を提供できれば、さらに議論することができます。
追加された 著者 Derek,
さて、あなたはいくつかの有効な点を挙げます。ただし、データベース構造自体は実際にはUIに関係しないようにすべきですが、REST応答自体を設計することに意味があるわけではないことに気付きます。 UIに関心がありますか?私たちは公開データAPIを作成しているのではなく、アプリ内でマークアップを生成するためにデータを取得するAPIを作成しています。
追加された 著者 doweio,