HATEOASはサーバーへの呼び出し回数を増やしますか？

Question

私はHESTOASをRESTAPIで使ったことが一度もありません.HATEOASを使ってHATEOASを使っていると理解しています。他のリソースや関連リソースを取得するためにURIをレスポンスに含めて送信する必要はありません。

しかし、HATEOASでは、呼び出し回数が増えていませんか？ カスタマーオーダー情報を取得したい場合、最初にカスタマー情報を取得し、そのオーダーのURIを動的に取得する場合は、余分な呼び出しではありませんか？

疎結合は理解できますが、RESTのこの成熟度レベルの正確な使用を理解していません。

Answer 1

なぜHATEOASは必要なリクエスト数を増やす必要がありますか？クライアントがURIを返すことなく、クライアントは状態のトランジションを実行することができます（詳細情報の収集、いくつかのタスクの呼び出しなど）。クライアントはURI自体を構築する方法についていくつかの知識が必要です（したがって、 ）クライアントは依然としてサーバー側でエンドポイントを呼び出す必要があります。だから、HATEOASは、クライアントからサーバーへのURIの生成方法に関する知識を移しています。

通常、サーバに送信されるリクエストは、いずれの場合もステートレスにする必要があるため、実際には問題にはなりません。負荷分散されたサーバー構造を使用している場合、追加の要求は実際にサーバーに顕著な影響を与えません。

何らかの理由でクライアントからサーバーに発行されたリクエスト数が気になる場合は、、つまりサブリソースのコンテンツを埋め込むことができます。ただし、顧客の場合受注が豊富で、応答が非常に大きく、クライアントがデータを使用しなくてもすべてのデータを管理する必要がある場合など、パフォーマンスに大きな影響を与える可能性があります。通常、応答内に多数のリスト項目を埋め込む代わりに、サービスはクライアントにURIを指示します。URIは、クライアントが必要に応じてこれらの情報を取得する方法を習得できる場所です。多くの場合、この種のURIは（顧客が発注した注文のような）データのページビューを提供します。

サービスによって処理される要求数を確実に増加させるためのページング可能な要求がある間に、全体的なパフォーマンスは向上しますが、サービスは注文データ全体をクライアントに返す必要がないため、実際の応答内容の長さを短くすることができます。

投稿をまとめるために、HATEOASはクライアントからサーバーに呼び出すためのURIを作成するロジックを移動することを目的としているため、サービスからクライアントをさらに分離します。クライアントが発行しなければならない実際の要求の数は、HATEOASの潮流ではなく、全体的なAPIの設計とクライアントの要件です。