55

私はHATEOASを明確かつ簡潔に理解しようとしていますが、WRTRESTの専門家ではありません。（私はそれを理解していると思います、このhttp://www.looah.com/source/view/2284のおかげで）。

誰かが同様に魅力的なブログ/記事WRTHATEOASを提案できますか？

4

5 に答える 5

68

ハイパーメディア制約（以前はHATEOASと呼ばれていました）は、ユーザーエージェントに指示を与えるために使用される制約です。

返された表現にリンクを含めることにより、サーバーは、現在のアプリケーションの状態に基づいて実行できるアクションを決定し、その目標を達成するために誰と対話するかを知るというユーザーエージェントの負担を取り除くことができます。

サーバーは、リクエストで受信したもの以外にユーザーエージェントの現在の状態を認識していないため、サーバーから返された表現以外の状態を使用しないようにすることが重要です。これにより、サーバーによって提供される使用可能なアクションが、ユーザーエージェントの状態を可能な限り完全に理解することに基づいていることが保証されます。

ハイパーメディア制約に準拠するユーザーエージェントは、ステートマシンのように機能します。ステート遷移は、現在の表現で使用可能なリンクをたどることによって発生します。返された表現が新しい状態になります。

このアプローチの利点は、非常に軽量なユーザーエージェントになる可能性があります。そのアクションは、受信した応答とその応答を取得したリンクのみに基づいている必要があるため、状態を管理するために必要なコードはごくわずかです。ユーザーエージェントコードは、GET thisの命令シーケンスではなく、宣言的かつ反応的になり、これを実行してから実行します。リンクをたどるためのメカニズムがあり、これを受け取ったときの多くのインスタンスがそれを実行します。

これがどのように機能するかの例として、WebブラウザとJavascriptを使用しないWebサイト以外を探す必要はありません。ブラウザには、HTML内のリンクに基づいたオプションが表示されます。そのリンクをたどると、ブラウザは現在の状態を、リンクをたどったときに取得した新しい状態に置き換えます。履歴内のリンクから状態を取得しているため、戻るボタンは機能します（または少なくとも機能するはずです）。状態は取得された表現に完全に基づいている必要があるため、ブラウザはページへのアクセス方法を気にする必要はありません。

現在のアプリケーションの状態は単一のサーバーの応答に基づいているため、この「状態管理」モデルは非常に制限される可能性があります。ただし、複雑なアプリケーションは、連携して動作する一連のユーザーエージェントを使用して構築できます。これは、AJAXが達成することの一部であり、個別のユーザーエージェントを使用して個別の要求を行うことができるため、事実上、別のステートマシンを管理できます。残念ながら、ほとんどの場合、JavaScriptリクエストを作成し始めると、RPCスタイルに戻ります。これは、Javascriptの自然な非同期性を考慮すると残念です。

于 2012-02-08T14:10:23.483 に答える
52

簡単に言うと、HATEOAS：出力するデータで、IDではなくURIを使用して他のリソースを参照します。

すべての短い定義として、私が今与えた定義は多くのレベルで間違っていますが、それはあなたにHATEOASの核心が何であるかを理解させるはずです。

さて、もう少し長い説明のために。

HATEOASの原則では、アプリケーションの状態はハイパーテキストリンクを介して進む必要があります。あなたがインターネットをブラウジングしていると考えてください。まず、アドレスバーにアドレスを入力する必要があります。その時点から、ナビゲーションはリンクをクリックするだけでほとんど進歩します。リンクをクリックすると、別のページに移動します。もう一度クリックすると、ここに別のページが表示されます。ブラウザはどのようにして最初のページから2番目から3番目のページに移動できましたか？<a>要素にエンコードされたURLを使用しました。

同様に、RESTアプリケーションがこの結果を生成する場合

<accomodation>
  <hotel info="http://example/hotel/0928374" price="200"/>
  <guest-house info="http://example/guest-h/7082" price="87"/>
</accomodation>

http://example/hotel/0928374その場合、受信側のアプリケーションは、最初のホテルがで利用可能であり、2番目のホテルがで利用可能であることを知るために外部の知識源にアクセスする必要はありませんhttp://example/guest-h/7082。

一方、アプリケーションが次のようなIDで応答を生成する場合

<accomodation>
  <hotel id="0928374" price="200"/>
  <guest-house id="7082" price="87"/>
</accomodation>

受信側のアプリケーションは、各宿泊施設の情報を利用できるURIを取得するためにIDをプレフィックスで構成する方法を事前に知っている必要があります（たとえば、「http://example/すべてのリクエストに追加してから、hotelホテルやguest-hゲストハウスに追加する」）。このメカニズムは、多くのDBアプリケーションで発生するメカニズムと似ていますが、ブラウザーの動作とは異なることがわかります。

HATEOASの原則に従うことが重要です。これにより、受信するアプリケーションを大幅に変更することなく、アプリケーションを拡張できます。URIをからに変更するとしhttp://example.com/hotel/0928374ますhttps://reviews.example.com/accommodation/0928374。HATEOASに従った場合、簡単な変更になります。戻り値を変更すると、受信アプリケーションは変更なしで引き続き機能します。代わりに、URIの作成方法に関する個別のドキュメントがある場合は、すべてのアプリケーション開発者に連絡して、ドキュメントが更新されたことを確認するように依頼する必要があります。変更を反映するためにコードを変更する必要があります。

免責事項：これは、問題の表面をかじっただけの簡単な答えです。しかし、これを取得すると、HATEOASの原則の80％を取得できます。

于 2012-02-08T13:47:24.717 に答える
5

この記事は私がそれを完全に理解するのに役立ちました。http://restcookbook.com/Basics/hateoas/

シンプルでエレガントです。

HATEOASは、アプリケーション状態のエンジンとしてのハイパーテキストの略です。これは、APIを介して道を見つけるためにハイパーテキストを使用する必要があることを意味します。例：

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>

アカウントに100ドル（US）があるという事実とは別に、4つのオプションがあります。それは、より多くのお金を入金する、お金を引き出す、別のアカウントに送金する、またはアカウントを閉じることです。「リンク」タグを使用すると、指定したアクションに必要なURLを見つけることができます。さて、銀行に100米ドルがなかったとしましょう。しかし、実際には赤字です。

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>

今、私たちは赤字で25ドルです。今、私たちは多くの選択肢を失い、お金を預けることだけが有効であることがわかりますか？赤字である限り、アカウントを閉鎖したり、アカウントからお金を送金したり引き出したりすることはできません。ハイパーテキストは、実際に許可されているものと許可されていないものを示しています：HATEOAS

于 2016-09-05T09:12:11.783 に答える
4

REST＆HATEOASの問題の1つは、インターフェース定義の可視性と制御の難しさと欠如です。従来のRPCスタイルの相互作用では、通常、APIを定義し、プロジェクトによって制御および管理できるIDLやWSDLなどのアーティファクトがありました。

HATEOASを使用すると、APIは動的に検出可能になり、一連の動作（状態の変化）として記述される場合があります。動作はコードで説明されています。API記述（WADL）は、インターフェース記述から生成されるコードではなく、コードから生成されます。

于 2012-02-09T07:53:50.600 に答える
3

HATEOASエンジンを使った私の個人的な経験から、最大の違いはデザイン自体の哲学です。

Webアプリケーションを構築する場合、2つのアプローチがあります。1つはRPCスタイルで、もう1つはRESTスタイルです。

状態をRPCスタイルでテストする必要がある場合は、結果を返すRPCプロシージャを呼び出す必要があります。このような設計アプローチでは、最初の呼び出しの後に返されたパラメーターをクライアントに保存して、その後の呼び出しで返されたパラメーターを使用できるようにする必要があります。これにより、クライアントとサーバーが緊密に結合され、システム全体がステートフルになります。

一方、RESTスタイルでは、RPCはありません。重要なのは、クライアントとサーバー間の相互作用です。状態の遷移については、クライアントはサーバーと対話して情報を取得する必要があります。修正される唯一のインタラクションは、ホームインタラクションです。残りはすべて、さまざまな相互作用を経るときにクライアントによって検出されます。

コンピュータサイエンスの観点からは、1つは手続き型であり、アルゴリズムです。一方、RESTスタイルは相互作用のパラダイムです。言語として相互作用パラダイムを採用するシステムは、HATEOASシステムを提供します。

于 2015-02-26T14:01:13.633 に答える