WebAPIの設計について。APIは１つの画面内で複数リクエストするのは普通ですか？

Question

リレーション関係にある複数のテーブルの情報をバックエンドから取得したいとき、
さらには複数ネストしたリレーション関係の情報を取得したい時、考えられる設計は、

①取得したい全てのテーブル情報を返すエンドポイントを１つ作る

②それぞれのリソースを取得する複数のエンドポイントにリクエスト送って欲しい情報を全て取得する。

RESTだと②のような設計になると思うのですが
フロントの非同期処理が複雑になるのと、そもそもHTTPリクエストが複数回送られるのは
サーバ側の負荷が増え、かつ速度が落ちるはずなのでユーザビリティ的にも良くないと考えます。

かといって①の方法だと仕様変更がおきたとき、複数のエンドポイントのソースの修正が必要になりうると思います。

自分はRESTを使わないWebAPIの開発しかしたことがないのでよくわからないのですが
RESTの思想で設計してる案件では、フロント側はPromisやasync/awaitを駆使して複数のAPIエンドポイントにfetchするような設計なのでしょうか？
やはりHTTPリクエストは1度で済ませるのが望ましいように思うのですが
このような設計は普通なのでしょうか？

なお、GrahpQL使えばこれらは解決するものでしょうか？

Comments

[退会済みユーザー]

> APIは１つの画面内で複数リクエストするのは普通ですか？

質問の意味が分からないのですが・・・

自分が Web API から想像することですが、まず「画面」というのはありません。複数のリクエストというのもありません。

ブラウザなりデスクトップアプリなりから、API の仕様に従って要求を送れば、仕様通りに応答が返ってくるということで、「複数リクエスト」という話が分かりません。

Web API の仕様を満たすために、Web API の中で（あくまで中で）複数のテーブルに複数の SQL 文を投げるなど複雑な操作をしているかもしれませんが、クライアント側からは単純に一回の要求一回の応答ということになると思ってますけど？

[退会済みユーザー]

あるページを開いた時
表示する情報の取得のためフロント側でAPIフェッチを行い、その時　複数のエンドポイントへのリクエストを送るのはどうなのかという問いです

＞Web API の仕様を満たすために
バック、フロント両方の設計に関する質問なので仕様というは開発側の自由ですが・・・

[退会済みユーザー]

依然として意味不明です。Web API 側の話ではなくてフロントエンドの話ですか？　だとすると表題にあった「WebAPIの設計について」というのはどういうこと？　ゴッチャになってませんか？

[hoshi-takanori]

いわゆる「1 screen 1 api call」ってやつですね。
https://qiita.com/qsona/items/9c062de2bb83491aec38
https://qiita.com/y-do/items/5efb9abdc052de87cf64
https://hack-le.com/endpoint/

Answer 1

RESTの思想で設計してる案件では、フロント側はPromisやasync/awaitを駆使して複数のAPIエンドポイントにfetchするような設計なのでしょうか？

１つの画面で複数のAPIエンドポイントにリクエストを投げることはよくあることだと思いますよ。

サーバ側の負荷が増え、かつ速度が落ちるはずなのでユーザビリティ的にも良くないと考えます。

一概にそうとは言えないのではないでしょうか。リクエストが分散されていることで、リクエストが複数のサーバーに分散されますし、逆に１つのリクエストで画面に必要なデータを取得するような場合、ペイロードが大きい時でも１つのサーバーでリクエストとレスポンスを処理する必要が生じます。

ユーザービリティーに関しても、リクエストがリソースごとに分散されてることで、例えば、ユーザー一覧のUI部分はレスポンスが先に返ってきたから先に表示し、そのほかのレスポンスがまだ返ってきていないUI部分ではローディングのUI表示をして、ユーザーの画面表示への体感速度をあげることができると思います。

GrahpQL使えばこれらは解決するものでしょうか？

複数のAPIサーバーをマイクロサービス化してGraphQLだったり、BFFという設計パターンを導入すれば、解決出来るのだと思います。