REST HATEOAS（成熟度レベル3）？
REST APIはHATEOASに準拠し、Richardsonのすべての成熟度レベルを実装する必要があると信じているプロジェクトに上級チームメンバーが参加しています（ http://martinfowler.com /articles/richardsonMaturityModel.html ）！
AFAIK most REST実装はHATEOASに準拠していないため、より多くの人がそれを行わないのには十分な理由があるはずです。複雑さの増加、フレームワークの不足（サーバー側とクライアント側） ）、パフォーマンスの懸念および...
どう思いますか？現実世界のプロジェクトでHATEOASの経験はありますか？
RESTコミュニティはだれもRESTは簡単です。HATEOASはREST建築。
あなたが示唆するすべての理由で人々はHATEOASをしません：それは難しいです。サーバー側とクライアントの両方に複雑さを追加します（実際に恩恵を受けたい場合）。
しかし、何十億もの人々がREST今日。Amazonで「チェックアウト」URLが何であるか知っていますか？私は知りません。しかし、私は毎日チェックアウトできます。変わりましたか？私は気にしません。
あなたは気にしないことを知っていますか？スクリーンを書いた人は誰でもAmazon自動化クライアントをこすり落とした。苦労してWebトラフィックをスニッフィングしたり、HTMLページを読んだりする人は、どのリンクをいつどのペイロードで呼び出すかを見つけます。
そして、Amazonが内部プロセスとURL構造を変更するとすぐに、これらのハードコードされたクライアントはリンクが壊れたため失敗しました。
それでも、カジュアルなWebサーファーはほとんど問題なく1日中買い物をすることができました。
これはREST=アクションです。テキストベースのインターフェイスを解釈および直観し、ショッピングカートで小さなグラフィックを認識し、実際に何を意味するかを理解できる人間によって強化されています。
ソフトウェアを書くほとんどの人はそうしません。自動化されたクライアントを書いているほとんどの人は気にしません。ほとんどの人は、最初に壊れないようにアプリケーションを設計するよりも、壊れたときにクライアントを修正する方が簡単だと感じています。ほとんどの人は、それが重要な場所に十分なクライアントを持っていません。
トラフィックの両側で専門の技術サポートとITを備えた2つのシステム間で通信するための内部APIを記述している場合、変更を迅速かつ確実に、変更のスケジュールで通信できる場合、RESTはあなたに何も買わない。
ユーザー数が多い大規模なサイトには、この問題があります。システムとやり取りする際に、気まぐれにクライアントコードを変更するように依頼することはできません。サーバー開発スケジュールは、クライアント開発スケジュールとは異なります。 APIの突然の変更は、両側のトラフィックと運用を混乱させるため、関係するすべての人が受け入れることはできません。
したがって、そのような操作は、バージョンが簡単で、古いクライアントが移行しやすく、下位互換性がありやすいため、HATEOASの恩恵を受ける可能性が非常に高くなります。
ワークフローの多くをサーバーに委任し、結果に基づいて動作するクライアントは、サーバーの変更に対して、そうでないクライアントよりもはるかに堅牢です。
しかし、ほとんどの人はその柔軟性を必要としません。彼らは2つまたは3つの部門のサーバーコードを書いています、それはすべて内部使用です。破損した場合は修正し、通常の操作に反映します。
柔軟性は、RESTまたは他の何かからのものであるかどうかにかかわらず、複雑さを生み出します。シンプルで高速にしたい場合は、柔軟性を持たずに「やるだけ」で完了します。抽象化とシステムへの逆参照を追加すると、スタッフはより困難になり、ボイラープレート、テストするコードが増えます。
REST=の多くは、「必要ない」という箇条書きに失敗します。もちろん、そうするまでです。
必要な場合は、それを使用し、レイアウトどおりに使用します。 RESTはHTTPを介してやり取りするものではありません。これまでになかった、それよりもはるかに高いレベルです。
ただし、RESTが必要で、RESTを使用する場合は、HATEOASが必要です。これはパッケージの一部であり、何が機能するかの鍵です。
はい、APIでハイパーメディアを使用した経験があります。利点の一部を次に示します。
探索可能なAPI：些細に聞こえるかもしれませんが、探索可能なAPIの能力を過小評価していません。データを参照する機能により、クライアント開発者はAPIとそのデータ構造のメンタルモデルを簡単に構築できます。
インラインドキュメント：リンク関係としてURLを使用すると、クライアント開発者がドキュメントを参照できるようになります。
単純なクライアントロジック：URL自体を構築するのではなく、単にURLを追跡するクライアントは、実装と保守が簡単になります。
サーバーはURL構造の所有権を取得します。ハイパーメディアを使用すると、サーバーが使用するURL構造に関するクライアントのハードコードされた知識が削除されます。
コンテンツを他のサービスにオフロードする：コンテンツを他のサーバー（CDNなど）にオフロードする場合、ハイパーメディアが必要です。
リンク付きのバージョン管理：Hypermediaは、APIのバージョン管理に役立ちます。
同じサービス/ APIの複数の実装：同じサービス/ APIの複数の実装が存在する場合、ハイパーメディアが必要です。サービスは、たとえば、投稿やコメントを追加するためのリソースを備えたブログAPIです。サービスがハードコードされたURLではなくリンク関係の観点から指定されている場合、同じサービスが異なるURLで複数回インスタンス化され、異なる企業によってホストされますが、単一のクライアントが同じ明確に定義されたリンクセットを通じてアクセスできます。
これらの箇条書きの詳細な説明については、こちらをご覧ください。 http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html
（同様の質問がここにあります： https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas ここで同じ説明をしました）
リチャードソンの成熟度レベル3は価値があり、採用されるべきです。 JørnWildtはすでにいくつかの利点をまとめており、Wiltによる別の回答がそれを非常によく補完しています。
ただし、リチャードソンの成熟度レベル3は、フィールディングのHATEOASとは異なります。リチャードソンの成熟度レベル3は、API設計に関するものです。 FieldingのHATEOASもAPI設計に関するものですが、クライアントソフトウェアは、リソースが、メディアタイプ。これには、特定のWebサイトに関する知識を持たないWebブラウザーなどの非常に汎用的なクライアントが必要です。 Roy Fieldingは用語RESTを作成し、HATEOASをRESTに準拠するための要件として設定しているため、質問はHATEOASを採用しますか？私たちはできると思います。説明させてください。
HATEOASを達成したとします。現在、アプリケーションのクライアント側は非常に汎用的ですが、リソースのセマンティクスに関する知識がないと、それらのセマンティクスを反映するようにリソースの表示を調整できないため、ユーザーエクスペリエンスが悪い可能性があります。リソース「car」とリソース「house」のメディアタイプが同じ場合（例：application/json）、それらは同じ方法で、たとえばプロパティのテーブル（名前/値のペア）としてユーザーに表示されます。
しかし、わかりました、私たちのAPIは本当にRESTfulです。
ここで、このAPIの上に2番目のクライアントアプリケーションを構築するとします。この2番目のクライアントは、HATEOASのアイデアに違反しており、リソースに関する情報をハードコーディングしています。車と家をさまざまな方法で表示します。
APIはまだRESTfulと呼ばれますか？私はそう思う。クライアントの1つがHATEOASに違反したのは、APIのせいではありません。
RESTful API、つまり理論的には一般的なクライアントを実装できるAPIを構築することをお勧めしますが、ほとんどの場合、必要なのはsome使いやすさの要件を満たすために、クライアントのリソースに関するハードコードされた情報。それでも、クライアントとサーバー間の依存関係を減らすために、できる限りハードコーディングしないようにしてください。
REST実装パターン [〜＃〜] jarest [〜＃〜] と呼ばれるHATEOASのセクションを含めました。
RESTレベル3 APIを構築しています。応答はHAL-Jsonです。HATEOASはフロントエンドとバックエンドの両方に最適ですが、課題が伴います。 HAL-Json応答内でACLを管理します（これはHAL-Json標準に違反しません）。
HATEOASの最大の利点は、フロントエンドアプリケーションにURLを記述したり推測したりする必要がないことです。必要なのはエントリポイント（_https://hostname_）だけで、そこからリンク内または応答内で提供されるテンプレートリンクを使用してリソースを参照するだけです。そのように、バージョン管理は簡単に処理でき、URLの名前変更/置換、フロントエンドコードを壊すことなくリソースを追加の関係で拡張します。
フロントエンドでのリソースのキャッシュは、自己リンクを使用した簡単なことです。また、ソケット接続を介してクライアントにリソースをプッシュします。これらのリソースもHALでレンダリングされるため、同じ方法で簡単にキャッシュに追加できます。
HAL-Jsonを使用するもう1つの利点は、従う必要がある文書化された標準があるため、応答モデルがどのように見えるかが明確であることです。
カスタマイズの1つは、セルフリンクオブジェクト内にアクションオブジェクトを追加したことです。このオブジェクトは、認証済みユーザーが各リソースで実行できるアクションまたはCRUD操作をフロントエンドに公開します（_create:POST_、_read:GET_、_update:PUT_、_edit:PATCH_、_delete:DELETE_）。このように、フロントエンドACLはREST API応答によって完全に決定され、この責任をバックエンドモデルに完全に移行します。
したがって、簡単な例を挙げると、次のような投稿オブジェクトをHAL-Jsonに含めることができます。
_{
"_links": {
"self": {
"href": "https://hostname/api/v1/posts/1",
"actions": {
"read": "GET",
"update": "PUT",
"delete": "DELETE"
}
}
},
"_embedded": {
"owner": {
"id": 1,
"name": "John Doe",
"email": "[email protected]",
"_links": {
"self": {
"href": "https://hostname/api/v1/users/1",
"actions": {
"read": "GET"
}
}
}
}
},
"subject": "Post subject",
"body": "Post message body"
}
_フロントエンドで行う必要があるのは、実行するアクションがアクションオブジェクトにあるかどうかを確認するAclServiceメソッドを使用してisAllowedを構築することだけです。
現在、フロントエンドでは次のようにシンプルに見えます：post.isAllowed('delete');
RESTレベル3は素晴らしいと思いますが、頭痛の種になる可能性があります。RESTおよび作業する場合は、レベル3でREST RESTの概念に厳密に従うことをお勧めします。そうしないと、実装時に道に迷ってしまいます。
私たちの場合、フロントエンドとバックエンドの両方を構築しているという利点がありますが、原則として違いはないはずです。しかし、私たちのチームで見た共通の落とし穴は、フロントエンドのニーズに「適合する」ようにバックエンドモデルを変更することで、フロントエンドの問題（アーキテクチャ）を解決しようとする開発者がいることです。
HATEOASはいくつかの実際のプロジェクトで使用しましたが、リチャードソンとは解釈が異なります。それがあなたの上司が望むものであるなら、私はあなたがちょうどそれをするべきだと思います。 HATEOASは、リソースにHTML Doctype、関連リソースへのハイパーリンク、およびGET以外の動詞の機能を公開するHTMLフォームを含める必要があることを意味します。 （これは、Acceptタイプがtext/htmlの場合です-他のコンテンツタイプはこれらの追加を必要としません。）アプリケーション全体のすべてのRESTリソースがネットワークアプリケーションには、直接関連する場合もしない場合もある複数のリソースが含まれている必要があります、またはXML、JSONなどのタイプがこれに従う必要があると考えられる理由（HATEOASはHTML固有です）。