私が現在理解しているように、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がどのように関連し続けるのかわかりません。意味は次のとおりです。JavaScriptでSPAをコーディングする場合、コードを記述するためにAPIで何ができるかを知る必要があります。
したがって、サーバーへのajax呼び出しを作成するため、さらにはUIを構築するために、リソース、サポートされるメソッド、それらが受け取ることを期待し、それらが返すものを知る必要があります。 UIを作成するとき、アカウントをリクエストした後、たとえばアカウントにデポジットできるか、UIでこのオプションを提供できないことを知っている必要があります。また、ajax呼び出しを構築するためのデポジットを行うには、URIを知る必要があります。
つまり、APIにリクエストを送信すると、リンクによってAPIをより適切に検出および使用できるようになりますが、クライアントを構築すると、構築しているアプリは単にリンクを見て、それ自体がレンダリングするわけではありません正しいUIと正しいajax呼び出しを行います。
では、HATEOASはクライアントにとってどのように重要ですか?なぜとにかくHATEOASに悩むのでしょうか。
私たちが構築しているアプリは単にリンクを見て、それ自体で正しいUIをレンダリングして適切なajax呼び出しを行うだけではありません
実際、これは正確にHATEOASがUIに与えるものです。 何ができるのではなく、いつが可能か。 [〜#〜] hal [〜#〜] のような正式なHATEOASは、質問のとおり、何が可能かを示すリンクを提供します。しかし、whenこれらのリンクが表示されるかどうかは、アプリケーションの状態によって異なります。したがって、リンクは(すでに実行されたアクションに基づいて)時間の経過とともにリソース上でchangeできます。
これにより、すべての可能な状態を含むUIを構築できますが、これらの状態がアクティブになるwhenには関係ありません。たとえば、rel="deposit"
の存在は、make deposit
フォームをレンダリングしてもよい場合に、UIに直接通知できます。これにより、ユーザーは値を入力し、リンクを使用して送信できます。
私が現在理解しているように、HATEOASは基本的にすべての応答リンクと一緒に、次に何をすべきかについての情報を一緒に送信することです
HATEOASは単なるリンクではありません。アプリケーション状態のエンジンとしての「ハイパーメディア」です。
説明で見落としているのは、コンテンツタイプ、つまりクライアントとサーバー間で受け渡されるハイパーメディアの正式な定義です。
HTMLはハイパーメディアの例であり、HATEOSが機能する理由の例です。 HTMLページ自体は、クライアント(つまりユーザー)がサイト内を移動できるようにするエンジンです。 HTMLを完全にナビゲート可能なWebサイトに表示する機能を備えたブラウザ。それは単に他のページへのリンクを渡すだけでなく、リンクにコンテキストを与える意味のある方法で、ブラウザがナビゲート可能なサイトを構築できるようにそれらを渡します。
そして最も重要なのは、ブラウザがWebサイト自体を事前にゼロで理解することでこれを実行できることです。ブラウザはHTTPとHTMLしか認識しません。その単純な理解に基づいて、ユーザーにナビゲートするためにニューヨークタイムズを提示できます。
これは、「ユーザー」が別のコンピュータプログラムであっても当てはまります。ハイパーメディア自体がナビゲーションのコンテキストを定義する必要があります。
動的に生成されたインターフェースを構築する必要はありません。ニースかもしれませんが、必須ではありません。動的なインターフェースを構築できない場合は、リンクを使用するだけで完了です。不利な点は、再びバックエンドにハードリンクされ、何かが変更されるとクラッシュすることです。
動的レイアウトの使用は非常に簡単ですが、
links.forEach(function(link) {
switch(link.rel) {
case 'deposit':
showDepositButton();
break;
case 'withdraw':
loadWithdrawForm(link.href);
showWithdrawButton();
break;
}
});
それはあなたのようなクライアントコードであなたを救います:
if (balance <= 0 && negativeBalanceAllowed === false) {
showWithdrawButton();
}
クライアントを変更せずに、許可されたネガティブポジションを(たとえば、お金を借りることによって)実装できます。