問題タブ [hateoas]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
638 参照

web-services - GUIアプリのHATEOAS APIでグローバルハイパーメディアを処理するには?

編集:明確にするために、この質問は、HATEOAS APIでのGUIアプリケーションの構築、ハイパーメディアの「発見可能性」(つまり、動的)の原則に基づいて構築されたインターフェースの設計方法、および「ホーム」に「リンク」する純粋な「モーダル」GUIの回避に特に対処することに関するものです。 "「常にオン」にする必要があるグローバル機能 (ハイパーメディア エントリ API ポイントで表される)。


Hypermedia As The Engine Of Application State (HATEOAS) を利用する厳密な REST API 実装では、グローバルに「常に有効な」アクションを示す/表すためにどのようなパターン (存在する場合) が使用されますか (そのような概念が本当に REST に存在する場合)?

メタの質問は、繰り返されるハイパーメディアを「除外」できるかということです。

/version簡単な例で、 のリソースがあるとしましょうAllow: OPTIONS HEAD GET。このリソースは何にも依存せず、他の場所で発生する可能性のあるステートフルな遷移の影響を受けません。

  1. /versionハイパーメディアが他のすべてのリソース要求とともに単純に送信されるという要件はありますか?

  2. または、別のパターンで、クライアントの動作がリンクして(キャッシュされている可能性があります)、常に有効な呼び出しHomeをトリガーしますか? /version(GUI 用語での「モーダル」パターン - このリソースを閉じて、ホームに戻り、先に進みます)

  3. または、特定のアプリケーション用に独立した分離モジュールを作成するための何らかの方法/パターンはありますか? (おそらくある種のネームスペース?)

複雑ではあるが疎結合の API では、オプション 1はハイパーメディアの地獄に埋もれてしまい、リソース呼び出しごとにペイロードの 80 ~ 95% が繰り返されます。これは「正しい」ように見えますが、とても厄介です。オプション 2 は、GUI クライアントの動作の奇妙な癖 (「家に帰る」まで有効な要素を非表示にする - モーダル タイプの操作) または、GUI クライアントが常に「知っている」帯域外アクションをハードコーディングすることによる多くの安らぎのない仮定につながります。有効。

オプション 3 は私の最初の質問に関連しています: フラグ、またはグローバルに有効なアクションを示すための他のパタ​​ーンはありますか? 一度送信すると (たとえば、ルート/ホーム リソースで)、その後の応答を「除外」できますか?

0 投票する
1 に答える
216 参照

rest - REST/HATEOAS: restul リンクをテンプレート化することは許容できるアプローチですか

私たちが開発しようとしている API の Layer3/HATEOS/RESTful/HAL 全体を調査しています。

これらすべてのリンクによって肥大化する可能性のあるデータのリストを公開します。リンクをテンプレート化するのはアイデアではありませんか?これは何と呼ばれますか? それについての言及が見つからないようです。それが良いアプローチではない場合、なぜですか?

仮想の休日検索 API を例にとると、エントリ ポイントは目的地と出発空港のリストを提供し、ユーザーはどちらか一方を使用して検索を開始できます。

次のようなものは、より効率的なアプローチでしょうか? (大まかに HAL に基づく) そして、そうでない場合はなぜですか?

}

0 投票する
1 に答える
556 参照

javascript - angular を使用した基本的な HATEOAS - エントリ ポイントのロード

HATEOAS スタイルの REST-api をクリーンに実装しようとしています。私のサーバー側は(疑似HTTPおよび疑似JSONで)次のようになります。

戻り値 (適切な Content-Type とすべてのジャズを使用):

したがって、これはアプリケーションの単一のエントリ ポイントです (これはHAL_linksに準拠しています)。あらゆる種類のクライアントは、そこからユーザーまたは注文リソースを見つける場所を知っています。典型的なことは、ログインしてからユーザーのリストを取得することです。GET /api-entry-point

これは、Angular アプリの場合、これらのリンクを取得することが最初に行うことを意味します。$httpHTTP 呼び出しを行うという約束を返すカスタム サービス (に基づく) を使用します。この promise は、アプリケーションの開始時に一度解決する必要があります。angularを使用してこれを確実に行うにはどうすればよいですか?

resolve属性 (on )を見てきましたが、$routeProviderすべてのルートが の解決に依存するのは退屈でばかげているようです/api-entry-point

私もチェックしましmodule.runたが、約束も解決しません。

これを解決するにはどうすればよいですか?方法はありますか、それとも別のアプローチ/フレームワークが必要ですか?

0 投票する
4 に答える
37646 参照

json - RESTful JSON コレクションに対して HATEOAS スタイルのリンクをどのように実装する必要がありますか?

物事をシンプルに保ち、名前の衝突を避けるために、私はこのようにレコード リソースにリンクをまとめています...

ただし、コレクションにリンクを実装する方法がわかりません。私は例を求めて Web をトロールするのに長い時間を費やしましたが、あまり無駄のないHALを使用する以外は、問題を解決できません。

つまり、配列をコンテナー オブジェクトにラップする必要があります。

しかし、これは単一のリソースとは異なるため、レコードをコレクションのように動作させ、コンテナーにラップします....

表面的には、これは非常に優れたソリューションのように見えます。結果の JSON は 1 レベル深くなりますが、HATEOAS が実装されているので、それで問題ありません。全くない。コレクションに戻ると、本当の痛みがやってきます。コレクションとの一貫性を保つために単一のリソースがコンテナーにラップされたので、変更を反映するためにコレクションを変更する必要があります。そして、これは醜いところです。非常に醜い。今コレクションはこんな感じ…

コレクションに HATEOAS を実装するためのより簡単なソリューションはありますか? それとも、データ構造を過度に複雑にすることを余儀なくされた HATEOAS に別れを告げるべきでしょうか?

0 投票する
1 に答える
258 参照

rest - ServiceStackを使用してhrefをRequestDtoに変換するにはどうすればよいですか?

リンクされたリソースの拡張をサポートする ReST API を構築していますが、ServiceStack のネイティブ バインディング機能を使用して URL を入力済みの「リクエスト DTO」オブジェクトに変換する方法がわかりません。

たとえば、私の API で、次のリクエストを使用してバンドに関する情報を取得できるとします。

バンドのアルバム リストを拡張したい場合は、次のようにします。

ServiceStack を使用していますが、既存のサービス メソッドを再利用してこのインライン展開を実行したいと考えています。

私の ServiceStack 応答 DTO は次のようになります。

私のServiceStackリクエスト/ルートオブジェクトは次のようなものです:

リクエストを処理する実際のサービスは次のようになります。

/bands/123/albums上記の例で、Van Halen のアルバム リストの HREF として文字列を計算したとします。

ServiceStack の組み込みバインディング機能を使用して、文字列/bands/123/albumsを BandAlbums の「リクエスト」オブジェクトに変換し、BandAlbumService に直接渡すことができます。データが入力された BandAlbumsDto オブジェクトを取得し、それを応答オブジェクトに含めるにはどうすればよいですか?

(もちろん、データベース ヒットを最小限に抑えるという点では、これがおそらく最適なアプローチではないことは承知しています。これについては後で考えます。)

0 投票する
1 に答える
2207 参照

ruby-on-rails-3 - Rails に HATEOAS を実装する方法

私は ActiveResource から始めましたが、すぐに壁にぶつかりました。基礎となるモデルで to_json および to_xml をオーバーライドするときに、ActiveResource を機能させることができませんでした。さらに、リソース表現が生成された xml ドキュメントにリンクを挿入することができませんでした。ところで、Rails 3.2.1 を使用しています。

私は少し調査を行い、その宝石について知りました。試してみましたが、なぜかうまくいきませんでした。だから私の質問は:

1 つのリソース (書籍など) を 1 つの Web サイト ( http://books.orgなど) でホストし、別のリソース (たとえば学生、http://students.org ) を別の Web サイトでホストしている場合、どうすればよいでしょうか。 HATEOS の完全な栄光で学生に自分自身を表すために本を手に入れますか?

私は、本のリソースを XML ドキュメントとして学生に提示することができました。これは、学生サイトでバニラの Rails ActiveResource を使用して行いました。から継承する Books リソースを作成しましたActiveResource::Base。次に and を指定したself.siteself.element_name、リモートの書籍サイトに対して初歩的な ActiveRecord のようなクエリを実行できるようになりました。私のために働いた唯一のものはBook.all、とBook.find(1). 表現にはすべてのデータベース列が含まれていたため、それでも満足のいくものではありませんでした。少なくともそれらのいくつかを削除したかったのですが、それは不可能であることが判明しました。

私はそのアプローチを放棄したので、アプリケーションの状態転送を駆動するリンクを含む、より洗練されたリソース (書籍など) の表現を構築できる実用的な例が Rails にあるかどうか疑問に思っています。このような単純な要件を Rails で実装するのが非常に難しいように思えるのは、信じられないことです。私がやろうとしているのは、リソースの機能を発見する際に消費者を導くいくつかのリンクを含むリソースの表現を作成することだけです。私は主にワークフローを実装することに関心があります。これは、階層化されたタマネギの皮をむくタイプの会話型発見プロセスです。

0 投票する
1 に答える
1263 参照

rest - HATEOAS クライアント ライブラリの生成

HALを使用して HATEOAS を容易にする注文管理用の RESTful API があるとします。

インターフェイスのセットを使用してクライアント (アプリケーション) を作成したいので、これらのインターフェイスの実装が DI-d ファクトリなどによって DI-d/ビルドされていると仮定すると、気にする必要はありません (気にする必要はありません)。それらが私の RESTful API によって支えられていること。例として (疑似 C#/Java):

私の質問は次のとおりです: API からOrder/インターフェースの実装を生成することは意味がありますか? Itemこれは、WSDL をエクスポートする C#/Web サービスで提供されるものと同様の方法を意味します。

API のスキーマをトラバースするための HATEOAS API を効果的に使用できるように、 andOPTIONSなどのリソースを実装することを考えていました。/orders/orders/{id}

もちろん、_linksオブジェクトのこの部分を任意のリソース (/orders/2たとえば ) で返すようにすることもできますが、それでは静的コード生成が妨げられます。

特定のリンクが提供された場合、関連するアクションが利用可能/実行されるべきであるという事実をカプセル化する賢明な方法があるかどうか疑問に思っています。

注: 念のために言っておきますが、私は実際には JavaScript (特に AngularJS) で作業しています。ただし、一連の概念的なインターフェイス/コントラクトを使用してアプリケーションを作成したいと考えています。