HATEOASベースのRESTfulサービスの利点
REST based（Java）と呼ばれているがHATEOASに準拠していない2つの商用アプリケーションがあるシナリオがあります。開発アクティビティはベンダーにアウトソーシングされます
プロジェクトの開発フェーズが完了し、機能テストの計画が立てられています。
機能テストを実行するためのテスト段階では、社内の技術者を優先しましたが、技術者はこれら2つのアプリケーションに関するビジネス/ドメインの知識を持っていません。開発者は、特定のデータベースエンティティを参照する各エンドポイントの目的を知っていました。
良い安らかなプログラミングは [〜＃〜] hateoas [〜＃〜] に準拠していることを学びました。
HATEOASは（表現（state transfer））を許可します
簡単な利点の1つは、ルートエンドポイントから開始してさまざまな状態に移動するだけでよいテストフェーズにありますビジネス/ドメインの知識は必要ありません APIエンドポイントは自己検出可能なため、アプリケーションの。
FacebookなどのパブリックプラットフォームはHATEOS準拠のRestfulサービスに準拠していません
HATEOASがRESTfulプログラミングの前提条件ではない場合、両者の違いは不明確です
python decorator（
@route('/')）でルートにマップされたサーバーサイドのビジネスロジック＆
RESTfulエンドポイント。
1）HATEOS準拠のRESTfulサービスの利点は何ですか？
2）HATEOAS準拠として、開発者がアプリケーションを再設計するには何が必要ですか？機能テストを正常に実行するため。
HATEOS準拠のRESTfulサービスの利点は何ですか？
つまり、サーバー側の制御を維持し、サーバーの内部に関するクライアントの知識を最小限に抑えます。
Amazonが商品ページだけを提供していて、商品を購入するためのリンクやフォームがない商品を想像してみてください。必要な製品IDを入力する別のサービス（ショッピングカートサービスなど）にアクセスするとします。それはかなり愚かなでしょうね。
HATEOASは、物事についてのリンクを提供するだけでなく、クライアントに特定のユースケースを満たすオプションを提供することを目的としています。
別の例：ホテル予約アプリケーションを実装する場合、部屋、予約、タイムスロットのデータをデータとして提供するのではなく、知る必要があるデータのみを提供します（内部IDはなく、そのようなもの）、そして特別に設計されたオプションのみガイド予約プロセスを通じてあなたに。
開発者がHATEOAS準拠としてアプリケーションを再設計するには何が必要ですか？機能テストを正常に実行するため。
主に考え方の変化。アプリケーションの「エンドポイント」または「リソース」は、人間向けのWebページと考えてください。あなたは人間に何を見せますか、そして人間があなたのアプリケーションをナビゲートできるようにするにはどのようなオプションを人間に与えますか？ HATEOAS準拠のアプリケーションインターフェイスの作成は、まさにそのようなものです。
正直なところ、それは思ったほど簡単ではありませんが、注意しなければならない技術的事項がいくつかあります。たった一点：もちろんしないでくださいクライアント側でAIが必要ですが、typedの表現が必要です（一般的なものではなく、適切なMedia-typeを使用します） ）、クライアント行うが知る必要がある（ブラウザがHTML、CSS、PNG、JPGなどを理解するのと同じように）。
HATEOASの大きなアイデアは、ハイパーメディアがアプリケーション状態のエンジンであるということです。リソースは、リソースの現在の状態で有効なアクションであるリンクを宣言します。 REST（Representational State Transfer）が実質的に無料で続くため、これは非常にエレガントです。クライアントは同期する必要がなく、サーバーとの状態ナビゲートリンクをたどることにより、アプリケーションの状態。
残念ながら、HATEOASは、開発者がAPIに対して持っている実際の要件を満たしていません。
HATEOASは、クライアントが適切なパラメーターを挿入したり、HTTPメソッドを選択したりできるように、リンクを何らかの形式のサービス記述言語で提供することを効果的に要求します。 HTML
<form>要素は、そのようなシステムの1つを提供します。ただし、クライアントをサービス記述インタプリタに変換する代わりに、サービス記述をクライアントにハードコーディングする方がはるかに簡単であることがよくあります。また、サーバー開発者は、機械で読み取り可能なサービスの説明を提供する代わりに、APIの安定性を確保する方が簡単です。
これは必ずしもHATEOASのせいではなく、これが私たちのツールの現実です。
ほとんどのREST APIは「ディープリンク」して1つのリクエストでいくつかのアクションを実行できますが、HATEOASは潜在的にいくつかのアクションを完了するためにナビゲートする複数のリンクを必要とします。
発見可能性に関する潜在的な利点は重要ではありません。クライアントは1回実装され（その間、発見可能性は開発者にとって役立つ可能性があります）、エンドポイントを再発見することなく何度も実行されます。
リソースが現在の状態で有効なリンクのみを提供するという点で、発見可能性の利点は残ります。たとえば、リソースが存在しない場合、削除するためのリンクは表示されません。または、クライアントに必要な権限がない場合、リソースにパッチを適用するためのリンクを取得できません。しかし、APIはとにかく無効なリクエストを処理する必要があり、有効なアクションに関するルールはすでにクライアントに認識されている可能性があるため、一般的なAPIはこの方法ではほとんどメリットがありません。
すべてのHTTP APIがRESTful設計を使用しているわけではなく、それが実際に問題を引き起こす可能性があります（たとえば、真のRESTful設計はHTTPキャッシングと非常に相乗効果があります）。特に、URLをアクションまたはエンドポイントとして誤解すると、RPCっぽいデザインになります。 What Woy Roy Fielding Doおよび少なくともconsideringのラウンドを行うと、HATEOASアプローチは、URLを使用してresourcesを表すためだけに役立ちます。多くの場合、適切なRESTデザインは、アクション/動詞をリソース/名詞に変換します。
1）HATEOS準拠のRESTfulサービスの利点は何ですか？
ここには3つの役割があります：server、user-agent、およびuser。このWebアプリケーションを例にとってみましょう。 「サーバー」にHTTPリクエストを送信し、HTMLなどの応答を返します。 Webブラウザーは、HTTP/HTMLなどの複雑さを隠し、やり取りするリンクやフォームなどの機能を提供する「ユーザーエージェント」です。ユーザーエージェントは、クライアントと呼ばれることがよくあります。あなたと私は「ユーザー」です。
RESTアーキテクチャスタイルが私たちに与えるものの1つは、クライアントとサーバーの分離です。このステートメントのクライアントはユーザーエージェントです（Webブラウザを考えてください）。StackExchangeは私たちなしでサイトを更新できますブラウザを更新する必要があります。StackExchangeがサーバーを更新する必要なくブラウザを更新できます。2つがHTTP/HTML/URIなどの共通言語を話している限り、それぞれが独立して進化できます。この共通言語は、 Uniform Interface。
REST APIsのコンテキストでは、どの要素がどの役割を果たしているかはそれほど単純ではありません。サーバーは引き続きサーバーです。ユーザーエージェントは通常、サーバーユーザーはアプリケーションです奇妙なことですが、ハイパーメディア（HATEOAS）から本当に得られるメリットを理解することが重要です。
Webで得られるのと同じ進化の特性をAPIから得るのが非常に難しいのは、Webのユーザーは人間であり、APIのユーザーはプログラムだからです。人間は、移動したボタンや新しいワークフローに簡単に適応できます。ほとんどの変更に対処するには、プログラムを更新する必要があります。
ただし、これはハイパーメディアがAPIに役に立たないことを意味するものではありません。通常、HTTPクライアントを介してAPIとやり取りします。 Webブラウザーと同様に、必要なHTTPクライアントを選択でき、HTTPを話すサーバーで動作します。
これに関する1つの問題は、APIを使用するために、プログラマーが数十のWeb標準に精通している必要があることです。したがって、最終的には、APIが実行できるすべてのことを実行するためにプログラムが呼び出すことができる関数を作成するHTTPの周りにラッパーを作成することになります。ハイパーメディアがない場合、これらのユーザーエージェントは、サーバーがサポートする機能に必ず結合する必要があります。サーバーが新しい機能を追加する場合、その機能をサポートするようにユーザーエージェントを更新する必要があります。
ここでハイパーメディアが助けになります。アプリが状態遷移を行う方法がハイパーメディアを使用してエンコードされ、サーバーから返されるリソースに含まれている場合、クライアントはこれらの対話ポイントをハードコーディングする必要がありません。プログラムがリンクをたどってユーザーエージェントとやり取りする場合、APIに新しい機能を追加するためにユーザーエージェントを変更する必要はありません。ただし、新しい機能を利用するには、プログラム（ユーザーと思われる）を更新する必要があります。
汎用的なユーザーエージェントがあり、APIに合わせて作成されたように感じたと想像してください。 HTTPとメディアタイプの技術的な詳細をすべて抽象化しているため、非常に使いやすくなっています。複数のAPIに同じユーザーエージェントを使用できます。あるAPIから別のAPIにリンクすることもでき、ユーザーエージェントは同じAPIであるかのようにスムーズに処理します。これは、ハイパーメディアで可能なことです。
2）HATEOAS準拠として、開発者がアプリケーションを再設計するには何が必要ですか？機能テストを正常に実行するため。
JSON Hyper-Schemaを使用して、それを常に実行しています。ハイパースキーマは、プレーンなJSONに適用してリンク/フォームをJSONに追加できるテンプレートのようなものです。レスポンスでLinkヘッダーをrel=describedbyとともに使用して、JSONレスポンスに適用するハイパースキーマを示すことができます。このアプローチの利点の1つは、ハイパーメディアを追加するためにJSONを変更する必要がないことです。 JSON APIと完全に下位互換性があります。
単純なプロキシサーバーを作成して、使用しているプレーンなJSON APIにハイパースキーマを追加することがよくあります。次に、これらのAPIをJsonaryで参照できます。 Jsonaryは、JSONハイパースキーマAPIを指定してユーザーインターフェースを作成できるユーザーエージェントです。
Jsonaryブラウザーで実行されているTODOリストAPIの例を次に示します。 http://json-browser.s3-website-us-west-1.amazonaws.com/?url=http%3A//hypermedia-todo.herokuapp.com/ 。これは最もきれいなインターフェイスではありませんが、ドキュメントなしでそれを使用する方法を理解できるはずです。リンクをたどってフォームに記入するだけです。
プレーンなJSON APIにハイパースキーマを追加するには、いくつかの制限があります。ハイパースキーマはJSONのテンプレートのようなものなので、JSONがデータを持っているものへのリンクしか表現できません。たとえば、ページングを見てみましょう。 4ページにいて、5ページへのnextリンクを提供したい場合、JSONに次のページが「5」であるという情報が含まれている場合にのみ、それを行うことができます。
HATEOS準拠のサービスに利点はありません。述べられている目標は、APIを「発見可能」にすることです。ただし、リソースで提供されるリンクの意味を解釈できるほどのAIを備えたクライアントを開発することはできませんでした。
サービスを準拠させるために必要なことについては、この質問では仕様が非常に不十分です。通常の解決策は、関連するリソースとメソッドのURLを提供する「リンク」ノードをjsonレスポンスに追加することです。
私の見解は、RESTとHATEOSは明らかに人間が読むHTMLであるように設計されています。機械が読むjsonではありません。しかし、人間はドキュメントを読んだり、あらかじめ書かれたclient。json APIにHATEOSリンクを追加しても、呼び出しに追加のデータが追加されるだけです。