「HATEOAS」はApplication Stateとどのような関係がありますか？

HATEOASは「アプリケーション状態のエンジンとしてのハイパーメディア」の頭字語です。「アプリケーション状態のエンジン」とは何ですか。特に、「ハイパーメディア」のエンジンはどうですか。

私が理解できる限り、HATEOASとHALなどの関連する標準はRESTの「発見可能性」の部分に対応しています。

春の議論それについては、のように要約したものです。

HATEOASを使用すると、出力により、仕様やその他の外部ドキュメントを検索せずに、サービスと対話する方法を簡単に収集できます。

たとえば、HAL準拠のJSONなどを使用してHATEOAS準拠の応答を行う場合、クライアントはルートAPI URL以外のリソースパスをハードコーディングする必要がないということです。

「アプリケーションの状態」とは関係がないように見えることを除いて、これは完全に理にかなっています。せいぜい、サーバー構成（つまり、リソース（サーバー構成）のURLを変更した場合）を使用することで、コンシューマはどこにあるかを見つけることができます。

HATEOASが何であるかを私が収集できたことについて少し詳しく説明すると、同じ説明ページからの抜粋があります。HATEOASがリソースの場所を発見する問題を解決したことが示されています。ただし、「アプリケーションの状態」とは関係がないようです。

単純なJSONプレゼンテーションは、伝統的に次のようにレンダリングされます。

{ 
    "name" : "Alice"
}

顧客データはありますが、データには関連するリンクは含まれていません。

HATEOASベースの応答は次のようになります。

{
    "name": "Alice",
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/customer/1"
    } ]
}

この応答には、その人の名前だけでなく、その人がいる自己リンクURLも含まれています。

RESTfulかどうかに関係なく、Webアプリケーションは一般に単なるデータサービスではありません。さまざまなリソースを公開し、いくつかの動作を提供するため、状態があります。リソースの状態（クライアントに依存せず、アプリケーションによって管理される）とアプリケーションの状態（クライアント固有）は区別されます。ステートレスアプリケーションは、（クライアント固有の）アプリケーション状態を格納しません。その代わり、それは、クライアントがそれを担当することができますし、（アプリケーション）の状態の前後に（したがって、「転送することを可能にするAPIを提供SテイトT REにransferを」STを）。クライアントの観点から見ると、Webアプリケーションは対話を可能にするAPIの背後にある状態マシンですが、状態の一部は要求を補足するためにクライアントによってコンテキスト情報として提供されます。

さて、RESTの学習中に、リチャードソン成熟度モデルと呼ばれるものに出会ったかもしれません。-WebアプリケーションAPIの「成熟度」（長年にわたって進化）を説明しますが、状況を把握するための参考資料として役立ちます。このモデルでは、最終レベルを除くすべての成熟度レベルが、本質的にRPC over HTTPを容易にするAPIを提供します。このスタイルのAPI設計では、HTTPがトランスポートメカニズムとして使用されますが、実際の通信はカスタムプロトコルを介して行われるため、対話するシステム（クライアントとアプリケーション）は、いわゆる「帯域外情報」に依存して通信します（このコンテキスト、これは、これらのシステムがハイパーテキスト/ハイパーメディアや既存のHTTPプロトコルなどを利用するのではなく、何らかのカスタム標準を使用して通信することを意味します。したがって、この場合、状態転送と状態遷移を駆動するもの（「アプリケーション状態のエンジン」）はハイパーメディアではありません。

最終的な成熟度レベルではHATEOAS制約が導入され、それによって初めてAPIがRESTfulになります。クライアントは初期URIを通じて対話を開始します。サーバーは、アプリケーションの状態の適切なハイパーメディアベースの表現（デバイス、クライアント、またはさまざまな条件により異なる場合があるため、RE ST での「再表示」）で応答します。これには、クライアントに自己記述的なアクションが含まれます次の状態遷移を開始します（つまり、ハイパーメディアがアプリケーションの状態を直接サポートし、駆動するようになります）。

「アプリケーションの状態はクライアント固有」というステートメントをピックアップできますか。それが私の理解です。[...]それはサーバー側のリソースの可用性と関係があり、クライアントの状態とは関係ありません（私が見ることができるように見えます）...

まず、同じページにいることを確認しましょう。これはクライアントの状態（クライアント自体の内部状態など）ではなく、特定のクライアントに固有のWebアプリケーションの状態です。

あなたが言及する例は実際にはそれをよく説明していませんが、返されるリンクのリストは基本的にサーバー上で動的に生成され、現在利用可能な状態遷移を表しているため、（特定のクライアントの）現在のアプリケーション状態をエンコードしています。アプリケーションで必要な場合（状態遷移メタデータに限定されない）、状態関連情報の他のビットを（両方向に）転送することを選択できますが、制約は、クライアント固有のデータを決して記憶しないことです。サーバー、それは売れ行きを損なうからです。また、この状態は完全である必要はありません（単独で見たときに完全に意味がある必要はありません）が、受信側が決定を下し、それに基づいてロジックを実行するのに十分でなければなりません。他には何もありません（つまり、

HATEOASは、統一されたインターフェース（一般的な標準とデータ交換フォーマット）を利用してクライアントとサーバーを分離し、サーバー側でハイパーメディアタイプによって定義された「契約」の背後でデータをシャッフルできるようにします。帯域外情報（カスタムプロトコル）は、RESTが目的とする方法でネットワークインフラストラクチャを活用しないことがよくあります。（以下の説明を参照してください。）

あなたの例では、クライアントはそのロジックをURIではなく、「rel」属性のようなメタデータ（または注釈）に基づいています。たとえば、ブラウザはリンク内のURIを気にせず、リンクの種類（クリック可能なリンク、URIを構築できるフォーム、スタイルシート参照など）を知る必要があるだけです。

コンテキストでのREST

残念ながら、RESTは流行語になり、誰もがRESTfulになる方法について話し合っていますが、RESTのコンテキスト全体が欠落しており、このコンテキストを理解せずにRESTアーキテクチャスタイルを理解することはできません（RESTが実際に抱えている問題は何か）解決しようとしています）。

RESTは、Webの背後にあるアーキテクチャを一般化したものです。私たちのほとんどにとって、Webはプラットフォームです。しかし、RESTを開発した人にとって、WWW は特定の要件を持つアプリケーションであり、世界規模のネットワークで実行されます。したがって、RESTは、いくつかの重要な点でWebのようなシステムで、特定のプロパティセットを満たす必要があるシステムを対象としています。

これらは、長寿命（数十年と考える）の大規模ネットワークシステムです。これらは、組織の境界（協力している会社など）にまたがるシステム、または大規模な組織の異なるサブエンティティ間の境界（異なる部門、さらにはチームなど）にまたがるシステムです。コラボレーションはありますが、関係するエンティティはすべて、主に独自の条件で、独自のペースで、独自のセキュリティ問題を抱えて運用（作業、ソフトウェアの開発および展開）し、すべて異なるデバイス、オペレーティングシステムなどを使用しています。相互のリソース（ドキュメント、サービス、データ）にアクセスし、それらへの参照を共有する必要がある一方で、大規模な調整を行うことなく、独立して段階的に進化することができます（実際、人々に調整された展開を行うことは難しい同じ組織内）。

サービスを提供するサービスは、クライアントへの影響を最小限に抑えながら、サービスバージョンの進化、ノードの追加、データのシャッフルなどを実行できる必要があります。拡張する必要があります。クライアント（それ自体がサービスである可能性があります）は、サーバー側でのこのすべてのアクティビティにもかかわらず、動作し続ける必要があります。これらのシステムは、将来予期せぬ方法で使用される可能性があります。それらがアクセスして交換するリソースは、多くの異なるタイプであり、さまざまな方法で内部的に（コード化、型付け、表現、構造化）（サービスプロバイダーによって）実現されますが、それでも、システム/ネットワーク全体では、リソースにアクセスし、データと応答を構造化する必要があります（統一されたインターフェイス）。

RESTはこれらすべてを考慮に入れ、ネットワークのプロパティを非常に考慮に入れます。これは、高レベルで（独自のビジネスドメイン内で）、要件と制約の点で上記で概説された（または志望する）アプリケーションのニーズに対処することを目的としています。

それはありますが、万能薬ではありません。コストとトレードオフがあります。特定のコミュニケーションスタイルを課し、パフォーマンスに影響を与えます。常に大まかな方法​​でデータを転送します。多くの場合、同じデータを繰り返し、一般化された形式で（したがって、サービスにとって最も効率的ではない可能性があります）、一連のメタデータを使用して、多くの場合中間ネットワークノード間で（したがって、Web上のすべてのキャッシュ-データの送受信が最小限に抑えられ、可能な場合はクライアントをサービスから遠ざけます）。ユーザーが認識するパフォーマンスは重要であり、クライアントの記述方法に影響します（これが、ブラウザーがすべてのダウンロードまたは準備が完了する前にページのレンダリングを開始する理由です）。しかし、上記の特性を備えたシステムを構築できるようにするには、喜んでそのコストを支払います。

逆に、要件や制約が異なるシステムを構築している場合、コストに見合わない場合があります。

RESTまたはHATEOASを理解したい場合は、まずWebを理解することから始める必要があります。HALは（事実上）HTMLの代替にすぎません。HTMLがどのように機能するかを理解していれば、HALの役割を理解する方がはるかに簡単です。

「アプリケーション状態のエンジン」とは何ですか？

フィールディングの論文の第5章。

RESTは4つのインターフェース制約によって定義されます。リソースの識別。表現によるリソースの操作; 自己記述的メッセージ; アプリケーション状態のエンジンとしてのハイパーメディア。- 均一なインターフェース

したがって、アプリケーションの状態は、保留中の要求、接続されたコンポーネントのトポロジ（一部はバッファリングされたデータのフィルタリングである可能性があります）、それらのコネクタでのアクティブな要求、それらの要求に応じた表現のデータフロー、およびそれらの処理によって定義されますユーザーエージェントが受け取った表現。- データビュー

したがって、モデルアプリケーションは、現在の表現セットの代替の状態遷移を調べて選択することにより、ある状態から次の状態に移動するエンジンです。当然のことながら、これはハイパーメディアブラウザのユーザーインターフェースと完全に一致します。ただし、このスタイルでは、すべてのアプリケーションがブラウザであるとは限りません。実際、アプリケーションの詳細は汎用コネクタインターフェースによってサーバーから隠されているため、ユーザーエージェントは、インデックスサービスの情報検索を実行する自動化ロボット、特定の基準に一致するデータを検索するパーソナルエージェント、またはメンテナンスにもなる可能性があります。スパイダーが壊れた参照または変更されたコンテンツの情報を巡回している- データビュー

Google検索の仕組みを考えてみましょう。ブックマークを使用して、ローカルにキャッシュされた検索フォームのコピーを更新し、フォームを読み込み、クエリをフォームに入力して送信し、結果を読み取ります。クライアントに組み込まれたGoogleの機能は必要ありませんでした。すべてHTMLの機能を使用しています。フォームに含まれているメタデータ。ブラウザーに（標準化された処理ルールを介して）残りのリソース（別名検索結果）の表現を返すHTTPリクエストを作成する方法を指示します。

HALも同じ役割を果たします。HAL対応クライアントは、処理ルールを適用して、表現内のリンクを検出し、それらのリンクを使用してインテリジェントな処理を実行できます。リンクを定義するJSON処理モデルには何もないため、JSON対応クライアントはできません。