ハイパーメディア、ハイパーメディアコントロール、ハイパーメディアフォーマットとは
私は現在「休憩中」の本を読んでいます。次の用語のハイパーメディア、ハイパーメディア形式、ハイパーメディアコントロール、ドメインアプリケーションプロトコルを理解できません。著者は、ドメイン固有のハイパーメディア形式の必要性を示唆していました。私はそれらをほとんど理解できませんでした。私はこれらの用語をグーグルで検索しましたが、正しい答えを見つけることができませんでした。誰もがこれらの用語を説明できますか？なぜapplication/xmlの代わりにドメイン固有のハイパーメディア形式が必要ですか？
ハイパーメディア=クライアントとサーバーが統一された表現（ハイパーリンクなど）で話しているという事実。
HyperMedia Control =リソースで操作を実行する必要があります。たとえば、製品はハイパーリンクドメイン/製品/ 001で表され、リソースはハイパーメディア制御ドメイン/製品/ 001 /編集およびドメイン/製品/ 001 /削除によって操作（編集および削除）できます。
最大の違いはアプローチにあります。手続き型システムは最初に操作を順次コード（Javaなど）の状態遷移として記述し、次に相互作用はHATEOASを提供するハイパーリンクとして製造されます。
しかし、システムは相互作用として直接アプローチし、相互作用を直接モデル化するため、ハイパーリンクを直接配信します。サンプルの例は http://www.masterkube.com/hateoas_technology.html です。
お役に立てれば。
これについて多くの混乱があります。なぜなら、自分自身を呼び出すほとんどのアプリケーションRESTはハイパーメディアを使用せず、REST。
ハイパーメディアは、HTML以外のコンテンツのハイパーテキストの一般化です。ハイパーテキストはハイパーメディアのサブセットであると言えます。ハイパーメディアは、すべてのリンク、ボタン、およびWebサイトを閲覧できるようにレンダリングされたすべてを備えたブラウザー内のHTMLであるか、またはリンクやアクションのような自動クライアントによって解析されるXMLまたはJSONドキュメントである人間はブラウザで、レンダリングされたリンクとボタンをクリックします。
[〜＃〜] hateoas [〜＃〜]は、クライアントとRESTアプリケーションをハイパーメディアで駆動するか、単純に言うと、クライアントは、多くのAPIが行うように、ドキュメントに記載されているURIパターンなどの帯域外情報に依存するのではなく、リソース自体の表現のリンクをたどって、必要なすべてのリソースのすべてのURIを取得する必要があります。
これは思ったより簡単です。これは、クライアントとRESTアプリケーションとの相互作用は、Webサイトを閲覧する人間のように正確であるべきだということを意味します。スタックオーバーフロー自体を例に考えます。質問のリストを表示するには、ドキュメンテーションWebサイトにアクセスせずに、質問をリストするためのURIテンプレートを取得し、プレースホルダーにユーザーIDを入力し、ブラウンサーに貼り付けます。別のドキュメントへのリンクをクリックするだけです質問のリストとして記述されており、正確なURIが何であるかを気にすることすらありません。
ハイパーメディア形式 tは、クライアントとサーバー間の契約を定義します。これは、ハイパーメディアアプリケーションのリソースの特定の表現に使用しているハイパーリンク対応のデータ形式です。たとえば、ユーザーリソースがある場合、クライアントがそのリソースの表現から正確に何を期待するのか、表現を解析して情報を抽出する方法を文書化する必要があります。 APIとやり取りする前に、クライアントは情報を抽出するためにパーサーを実装する必要があります。リソースのプロパティとその意味、期待するリンク関係、利用可能な状態遷移などを知る必要があります。
Hypermedia controlsは、使用可能な状態遷移とその実行方法をクライアントに伝えるハイパーメディア形式のプロトコルメソッドとリンク関係の組み合わせです。たとえば、質問には、POSTメソッドのペイロードとしてAnswer表現を期待するrel=post_answerリンクがあり、それに関連する新しいAnswerリソースが作成されます。
ハイパーメディア形式のセットを定義したら、domain specific media-typeを使用して、特定のインタラクションに使用されているハイパーメディア形式を正確に決定する必要があります。 application/xmlなどの一般的なメディアタイプは、データ形式の解析方法をクライアントに伝えるだけで、パーサーによって抽出された情報については何も言いません。たとえば、ドキュメントにメディアタイプapplication/vnd.mycompany.user.v1+xmlがあり、クライアントがそれがXML形式のUserリソースのバージョン1.0表現であることを知っているとします。プロパティ、リンクなどを追加または削除してリソースを変更する場合、バージョン番号を変更できます。クライアントはAcceptヘッダーを使用して実装されたバージョンを要求できるため、クライアントは破損しません。また、XMLやJSONなど、同じリソースに対して複数の形式を提供したり、HTMLで人間が読み取れる表現を提供することもできます。
基礎となるプロトコルであるHTTPをすべてまとめてラップすると、ハイパーメディア形式とメディアタイプによって定義されたコントラクトドメインアプリケーションプロトコルがあります。これは、アプリケーションによってアドバタイズされるリソースと利用可能な状態遷移のセット全体です。
言うまでもありませんが、インターネットで見られるいわゆるREST APIの99％は、このすべてに準拠しているわけではありません。それらのほとんどは、 REST制約。すべての制約が本当に必要ではない場合があります。開発者がREST.