クライアント側のHATEOASのポイントは何ですか？

私が現在理解しているように、HATEOASは基本的に、次に何をすべきかについての情報を各応答リンクと共に送信することに関するものです。簡単な例の1つは、インターネット上で簡単に見つかります：銀行システムとアカウントリソース。この例は、アカウントリソースへのGET要求後のこの応答を示しています

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">100.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

データとともに、次に何ができるかを示すリンクがあります。残高がマイナスの場合、

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">-25.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
</account>

入金のみできるように。Fiddlerを使用している場合、またはブラウザーで要求を行っている場合、何ができるかを簡単に確認できます。この種の情報は、APIの機能を発見するのに役立ち、サーバーはクライアントから切り離されます。

ただし、ポイントは、Javascriptを使用したSPAやAndroidアプリなど、クライアントを構築するときに、HATEOASがどのように関連し続けるかを見ることができないということです。つまり、SPAをJavaScriptでコーディングしている場合、コードを記述するためにAPIで何ができるかを知る必要があります。

そのため、サーバーにajax呼び出しを記述し、さらにはUIを構築するために、リソース、サポートされるメソッド、受信するもの、返すものを知る必要があります。UIを構築するとき、アカウントをリクエストした後、たとえば、アカウントにデポジットすることができます。そうしないと、UIでこのオプションを提供できません。また、Ajax呼び出しを構築するためのデポジットを行うには、URIを知る必要があります。

つまり、APIにリクエストを行うと、リンクによってAPIの検出と使用が改善されますが、クライアントを作成すると、作成するアプリは単にリンクを見てからそれ自体をレンダリングしません正しいUIを作成し、適切なAjax呼び出しを行います。

それでは、クライアントにとってHATEOASはどのように重要ですか？とにかくHATEOASに悩まされるのはなぜですか？

作成しているアプリは、単にリンクを見てから、正しいUIをレンダリングして適切なAjax呼び出しを行うだけではありません

実際、これはまさに HATEOAS が UIに与えるものです。可能なことではなく、可能なときに。HALのような正式なHATEOAS は、質問が述べているように、可能なことを示すリンクを提供します。ただし、これらのリンクが表示されるタイミングは、アプリケーションの状態によって異なります。そのため、リンクは、リソース上で（既に実行されたアクションに基づいて）時間とともに変化する可能性があります。

これにより、可能なすべての状態を含むUIを構築できますが、それらの状態がいつアクティブになるかは気にしません。たとえば、の存在によりrel="deposit"、make depositフォームをレンダリングしてもよいかどうかをUIに直接伝えることができます。これにより、ユーザーは値を入力し、リンクを使用して送信できます。

私が現在理解しているように、HATEOASは基本的に、各応答リンクと一緒に次に何をすべきかについての情報を送信することです

HATEOASは単なるリンクではありません。アプリケーション状態のエンジンとしての「ハイパーメディア」です。

説明にないのは、コンテンツタイプ、つまりクライアントとサーバー間で渡されるハイパーメディアの正式な定義です。

HTMLはハイパーメディアの例であり、HATEOSが機能する理由の例です。HTMLページ自体は、クライアント（つまりユーザー）がサイト内を移動できるようにするエンジンです。ユーザーに完全にナビゲート可能なWebサイトを表示するHTMLをレンダリングする機能のみを備えたブラウザ。リンクを他のページに渡すだけでなく、リンクにコンテキストを与える意味のある方法で、ブラウザがナビゲート可能なサイトを構築できるようにリンクを渡します。

そして最も重要なことは、ブラウザーがWebサイト自体を事前にZEROで理解することでこれを実行できることです。ブラウザはHTTPとHTMLのみを知っています。その単純な理解に基づいて、ユーザーにNew York Timesを提示してナビゲートすることができます。

これは、「ユーザー」が別のコンピュータープログラムであっても保持されます。ハイパーメディア自体がナビゲーションのコンテキストを定義する必要があります。

動的に生成されたインターフェイスを構築する必要はありません。いいかもしれませんが、必須ではありません。動的インターフェイスを構築できない場合は、リンクを使用するだけで完了です。欠点は、あなたが再びバックエンドにハードリンクされ、何か変更があればクラッシュすることです。

動的レイアウトの使用は非常に簡単です。

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

    case 'withdraw':
      loadWithdrawForm(link.href);
      showWithdrawButton();
      break;
  }

});

次のようなクライアントコードを節約できます。

if (balance <= 0 && negativeBalanceAllowed === false) {
  showWithdrawButton();
}

クライアントを変更することなく、許可された負のポジションを実装できます（たとえば、お金を借りることによって）。