これには明確な答えはありませんが、最短の答えは...
WebApi の場合、これに制限はありません。制限は、サーバーが処理できるものと、サーバーで実行するコードがどれほど効率的であるかによって決まります。
...しかし、あなたが尋ねたので、サーバーとアプリケーションについて想定できるいくつかの基本的なことを考えてみましょう...
- 同時接続
典型的なサーバーは、「c10k」のような問題で知られています... https://en.wikipedia.org/wiki/C10k_problem ...そのため、同時接続数に厳しい制限が課せられます。
各 WebApi 呼び出しが、たとえば Web ページ上の AJAX 呼び出しから行われたと仮定すると、事態が悪化する前に約 10,000 接続の制限が与えられます。
2.依存関係関連のオーバーヘッド
次に、問題のコードの複雑さを考慮すると、SQL クエリなどを実行する際にボトルネックが発生する可能性があります。私は、10 以上の db クエリを実行するビジネス ロジックを持つ WebApi コントローラーを頻繁に作成しましたが、ここでのオーバーヘッドが問題になる可能性があります。
- フィード イン オーバーヘッド
サーバーへのネットワーク帯域幅はどうですか? 各呼び出しで 1MB のデータをストリーミングしていると仮定しましょう。そのサイズのメッセージで 1Gb/s イーサネット回線を詰まらせるのにそれほど時間はかかりません。
- 処理オーバーヘッド
複雑な計算 (複雑な 3D データのメッシュ生成など) を行う Api を作成したと仮定すると、各リクエストでしばらくの間、CPU を簡単にチョークすることができます。
- タイムアウト
サーバーがリクエストを受け入れることができ、リクエストが非同期で行われたと仮定すると、最大の問題は、応答をどれくらい待つ準備ができているかということです。これが非常に短いと仮定すると、各リクエストが応答を必要とする前に解決する時間がある問題の数を減らすことができます。
...
ご覧のとおり、これは決して網羅的なリストではありませんが、あなたが尋ねた質問の複雑さを概説しています. そうは言っても、WebApi (フレームワーク) には制限がないと主張したいと思います。何が可能かを判断するための制限があるのは、実際にはその周りのインフラストラクチャにかかっています。