HATEOAS：簡潔な説明
私はHATEOASを明確かつ簡潔に理解しようとしていますが、私は決してWRT RESTの専門家ではありません。 （私はこれのおかげで、それは理解できると思います http://www.looah.com/source/view/2284 ）。
誰もが同様に魅力的なブログ/記事WRT HATEOASを提案できますか？
ハイパーメディア制約（旧称HATEOAS）は、ユーザーエージェントに指示を提供するために使用される制約です。
返された表現にリンクを含めることで、サーバーは現在のアプリケーションの状態に基づいて実行できるアクションを決定するのユーザーエージェントから負担を取り除き、それを実現するために対話するユーザーを知ることができますゴール。
サーバーはリクエストで受け取るもの以外にユーザーエージェントの現在の状態を認識していないため、ユーザーエージェントはサーバーから返された表現以外の状態を使用しないようにすることが重要です。これにより、サーバーによって提供される使用可能なアクションが、ユーザーエージェントの状態を可能な限り完全に理解したものに基づいていることが保証されます。
Hypermedia制約に準拠するユーザーエージェントは、ステートマシンのように機能します。この場合、現在の表現で状態遷移はリンクをたどることによって引き起こされますを使用できます。返された表現は新しい状態になります。
このアプローチの利点は、非常に軽量のユーザーエージェントになる可能性があります。アクションは受信した応答とその応答を取得したリンクに完全に基づいているため、状態を管理するためのコードはほとんど必要ありません。 ユーザーエージェントコードは宣言型になりますとリアクティブ、GETの命令シーケンスではなく、これを実行してから実行します。これは、リンクをたどるメカニズムと、これを受け取ったときの多くのインスタンスがこれを実行するだけです。 。
これがどのように機能するか例については、WebブラウザーとJavascriptを使用しないWebサイト以外を探す必要はありません。ブラウザには、HTML内のリンクに基づくオプションが表示されます。そのリンクをたどると、ブラウザは現在の状態を、リンクをたどったときに取得した新しい状態に置き換えます。履歴のリンクから状態を取得しているため、[戻る]ボタンは機能します（少なくとも機能するはずです）。状態は完全に取得された表現に基づく必要があるため、ブラウザはページへの到達方法を気にする必要はありません。
現在のアプリケーションの状態は単一のサーバーの応答に基づいているため、この「状態管理」モデル非常に制限される可能性があります。ただし、複雑なアプリケーションは、連携する一連のユーザーエージェントを使用して構築できます。これは、AJAXが達成することの一部です。これにより、個別のユーザーエージェントを使用して個別のリクエストを作成できるため、実際には別のステートマシンを管理できます。残念ながら、ほとんどの場合、 Javascriptリクエストの作成を開始したときは、RPCスタイルに戻してください。これは、JavaScriptの自然な非同期性を考えると残念です。
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をプレフィックスでどのように構成する必要があるかを事前に知っている必要があります（たとえば "add http://example/ to everyリクエストし、ホテルにはhotelを追加し、ゲストハウスにはguest-hを追加します "）。このメカニズムは多くのDBアプリケーションで発生するものと似ていますが、ブラウザの動作とは異なります。
HATEOASの原則に従うことが重要です。これにより、受信側のアプリケーションに大幅な変更を加えることなくアプリケーションを拡張できます。 URIをhttp://example.com/hotel/0928374からhttps://reviews.example.com/accommodation/0928374に変更するとします。 HATEOASをフォローした場合は、単純な変更になります。戻り値を変更して、次のようにします。受信アプリケーションは、変更を加えなくても動作し続けます。代わりに、URIの作成方法に関する個別のドキュメントがある場合は、すべてのアプリケーション開発者に連絡し、ドキュメントが更新されたことを通知して、変更を反映するようにコードを変更するよう依頼する必要があります。
免責事項：これは、問題の表面をなぞっただけの簡単な答えです。しかし、これを取得すると、HATEOASの原則の80％が得られます。
この記事は、それを完全に理解するのに役立ちました。 http://restcookbook.com/Basics/hateoas/
シンプルでエレガントです。
HATEOASは、Hypertext As the Engine Of Application Stateの略です。つまり、ハイパーテキストを使用して、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
REST＆HATEOASの1つの問題は、インターフェース定義の可視性と制御の難しさと欠如です。従来のRPCスタイルの対話では、通常、APIを定義するIDLやWSDLなどのアーティファクトがありましたまた、プロジェクトによって制御および管理できます。
HATEOASを使用すると、APIは動的に検出可能になり、一連の動作（状態の変化）として説明できます。動作はコードに記述されています。 API記述（WADL）は、インターフェース記述から生成されるコードではなく、コードから生成されます。
HATEOASエンジンでの個人的な経験から、最大の違いはデザイン自体の哲学です。
Webアプリケーションを構築する場合、2つの方法があります。 1つはRPCスタイルで、もう1つはRESTスタイルです。
状態をRPCスタイルでテストする必要がある場合、結果を返すRPCプロシージャを呼び出す必要があります。このような設計手法では、最初の呼び出しの後に返されたパラメーターをクライアントに格納して、その後の呼び出しで返されたパラメーターを使用できるようにする必要があります。これにより、クライアントとサーバーが密結合され、システム全体がステートフルになります。
REST=スタイルでは、RPCはありません。重要なのは、クライアントとサーバー間の相互作用です。状態の遷移では、クライアントはサーバーと相互作用して情報を取得する必要があります。修正される唯一の対話はホームの対話であり、残りはすべて、さまざまな対話を通過するときにクライアントによって発見されます。
コンピュータサイエンスの観点からは、1つは手続き型で、アルゴリズムに基づいています。ここでRESTスタイルは相互作用パラダイムです。言語として相互作用パラダイムを採用するすべてのシステムは、HATEOASシステムを提供します。