タグ付けされた質問 「hateoas」

最近、アプリケーション状態のエンジン（HATEOAS）としてのハイパーメディアについて読んでいます。これは、Web APIを「真にRESTful」とする制約です。基本的に、現在の状態から可能な遷移へのすべての応答にリンクを含めることになります。 HATEOASが私の理解に基づいていることを説明させてください。何かを見逃した場合は、訂正してください。 / GET: { "_links": { "child": [ { "href": "http://myapi.com/articles", "title": "articles" } ] } } /articles?contains=HATEOAS GET: { "_items": [ { "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" }, { "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" } ], "_links": { "self": { "href": …

61 rest  http  hateoas 

私が現在理解しているように、HATEOASは基本的に、次に何をすべきかについての情報を各応答リンクと共に送信することに関するものです。簡単な例の1つは、インターネット上で簡単に見つかります：銀行システムとアカウントリソース。この例は、アカウントリソースへのGET要求後のこの応答を示しています 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> データとともに、次に何ができるかを示すリンクがあります。残高がマイナスの場合、 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> 入金のみできるように。Fiddlerを使用している場合、またはブラウザーで要求を行っている場合、何ができるかを簡単に確認できます。この種の情報は、APIの機能を発見するのに役立ち、サーバーはクライアントから切り離されます。 ただし、ポイントは、Javascriptを使用したSPAやAndroidアプリなど、クライアントを構築するときに、HATEOASがどのように関連し続けるかを見ることができないということです。つまり、SPAをJavaScriptでコーディングしている場合、コードを記述するためにAPIで何ができるかを知る必要があります。 …

35 rest  client-server  hateoas 

私が見たさまざまな講演やRESTでスキャンしたチュートリアルは、「発見可能性」と呼ばれるものを強調しているようです。私の限られた理解では、この用語は、クライアントがアクセスできることを意味するようですhttp://URL-できることのリストを自動的に取得します。 私が理解できないのは、「ソフトウェアクライアント」は人間ではないということです。これらは、提供されたリンクをどうするかを正確に理解するための直感的な知識を持たない単なるプログラムです。Webサイトにアクセスして、表示されたテキストとリンクを理解し、それに基づいて行動できるのは人々だけです。 クライアントの人間の開発者が提示されたリソースを実際に実験しない限り、そのような発見可能なURLにアクセスするクライアントコードが実際に何もできないとき、発見可能性のポイントは何ですか？これは、ドキュメンテーションマニュアルで利用可能な機能のセットを定義するのとまったく同じように見えますが、異なる方向からだけで、実際には開発者のためにより多くの作業を伴います。なぜ、実際のRESTリソースの外部のドキュメントで実行できることを事前定義するこの2番目のアプローチが劣っていると考えられますか？

20 rest  api  hateoas 

正しく理解できれば、RESTはWebのアーキテクチャの記述モデルとしてRoy Fieldingによって正式化されました。AFAIK FieldingはRESTが良いと主張したわけではなく、Webの事実上のアーキテクチャを説明しているだけでした。Webはこの時点ですでに非常に成功した分散ハイパーテキストシステムを証明しているため、この種のRESTは、主に人間がナビゲートして消費する分散ハイパーメディアのドメインの成功したアーキテクチャとして検証されます。 REST Webサービスは、RESTアーキテクチャをAPIに適用することで作成されました。しかし、実際にはRESTがこのドメインに望ましいアーキテクチャであると考える理由はありますか？より具体的には、HATEOASがマシンツーマシン通信の有益な設計原則であるという証拠はありますか？ 私の懸念は、よく知られているコンテンツタイプ（HTML、画像、ビデオなど）がほとんどなく、クライアントがそれらを使用する方法を知っているため、HATEOASはハイパーメディアに意味があることです。ただし、APIの場合、コンテンツタイプは非常に具体的であり、クライアントがそれらを消費するように特別にプログラムされている場合にのみ、クライアントが意味のある方法で消費できます。クライアントにURLを返すだけでは、クライアントは指定されたリソースを消費できません。

15 rest  hateoas 

HATEOAS制約を使用してRESTサービスを構築する場合、リンクを介してリソースの存在を宣伝するのは非常に簡単です。あなたGETは私のサイトのルートにa を作成し、私はすべての第1層リソースをリストするルートドキュメントで応答します。 { users: { href: "/users" } questions { href: "/questions" } } これらのhref値の読み取り方法を理解しているクライアントは、これらの値に対してGET要求を実行し、アプリケーションで使用可能な現在のすべてのリソースを発見できます。 これは基本的なルックアップシナリオではうまく機能しますが、リソースがクエリ可能かどうかは示しません。たとえば、次のことを実行するのが妥当な場合があります。 GET /users?surname=Smith リソースの事前の知識がなくても、クライアントが一貫したクエリを形成できる十分な情報でこのクエリ機能を表現できる形式はありますか？ さらに、クライアントがPOST期待された場所で特定の場所への実行を許可されていることを表現する方法はありますか。たとえば、クライアントが新しい質問リソースを作成するために以下を実行することが期待できます。 POST /questions { title: "Are there strategies for discovering REST services using HATEOAS?", body: "When building a REST service with the HATEOAS constraint, it's very..." } 人間が使用する形式としてHTMLを使用する場合、フォームとプロンプトを使用してこれを多く表現し、サービスで実行できる操作を人間が発見できるようにすることができます。 クライアントにとって同様のことができるフォーマットはありますか？

10 design  rest  hateoas 

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も含まれています。

9 rest  hateoas 

HATEOAS APIでは、可能な状態遷移を表すリンクが返されます。適合クライアントはそれらのリンクを取得してたどるだけですが、不適合クライアントが提供されたリンクをたどるのではなくURIを構築している場合、返される最も適切なステータスコード/応答は何でしょうか？ 400は、応答本文のいくつかの情報と一緒に機能します-これは私たちが現在行っていることです 403リクエストが機能しない可能性があることを意味するため、間違っていると思いますが、将来的にリンクが使用可能になる可能性があります 404はもっともらしいようです-この時点ではリソースは存在しません 人々はどう思いますか？条件付き要求は古い応答（結果として412sなど）に基づいて要求を処理できることを知っていますが、これは少し異なる状況です。 更新： これらのタイプの無効な操作に対する正しい応答は404であることがわかりました。リクエストの構文が正しい場合、有効なリソースに送られますが、ビジネスルールに違反しています。次に、いくつかの不自然な例を示します。 クライアントが、互いに20％以内でなければならない2つの数値を提供できるとしましょう。 クライアントがいくつかの計算を経た数値を提供できるとしましょう。その結果は、提供された元の数値が正しくなかったことを示しています。 400はこれらの正しい応答ですか？

8 rest  api-design  hateoas