各コンシューマーリクエストに基づいてAPI内のサービスコールを決定する
現在、私は多くの異なる消費者に役立つレストAPIサービスを持っています。 APIのエンドポイントの1つは、注文を取得するためのものです。 1つのアプリケーション内で、他の外部APIに対して5つの異なるサービス呼び出しを行い、応答を生成して呼び出し元に返します。
私のAPIのコンシューマーの半分は、他の3つのサービスの応答を必要としません（応答を生成するために合計5つの外部サービス呼び出しがあります）。それらのいくつかは、注文に関する基本的な情報を見たいだけです。それらの消費者にとって、2つのAPI呼び出しだけで、コンテンツを自分の側で生成できます。
ただし、他の残りのコンシューマについては、応答全体を使用します
そのため、場合によっては、応答時間が急速に増加します。消費者は特定のサービスの応答を使用したくないとしても、いずれにしてもそのサービスを待つ必要があります。
消費者の要求に応じてどのサービスを呼び出すかを決定する方法はありますか？
まもなく、APIのコンシューマーに応じて、どのサービスを呼び出す必要があるかをシステムに決定させたいと思います。
注：アプリケーションはモノリシックです。マイクロサービスではありません。 5つのAPI呼び出しはすべて同じアプリケーション内で行われます。
GraphQl の「何を求めているか」というアプローチの優れたユースケースがあります。残念ながら、RESTのユビキタス性を壊して、クライアントとサーバーの部分を書き直す必要があります。
JSON：APIは、私が気に入っている別のアプローチ 関連するリソースリンク を形式化しています。このアプローチでは、クライアントが必要とするであろうとサーバーが予想する関連リソースへのリンクを含めることができます。関連するオブジェクト自体も含めることができます。このようにするためにJSON：APIを使用する必要はありませんが、非常にきれいに行う方法が書かれています。
/ users /：id/addressなどのように、返却にコストがかかる部分がアドレスである場合は、オブジェクトを分割する必要があります。