問題タブ [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 に答える
115 参照

web-services - RESTful検索。実際のリソースまたはURIを返しますか?

このすべてのRESTのものにはかなり新しい。

APIを設計していますが、検索クエリから何を返すのかわかりません。クエリ全体に一致するすべてのオブジェクトを返すだけだと思っていましたが、 HATEOASについて少し読んだ後、代わりにURIのリストを返す必要があると思いますか?

これはアイテムのキャッシュに役立つことがわかりますが、実際のオブジェクト情報を取得するために必要な後続の複数のHTTPリクエストによって多くのオーバーヘッドが発生するのではないかと心配しています。

私は誤解していますか?代わりにオブジェクトインスタンスまたはURIを返すことは許容されますか?

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

c# - Web API でハイパーメディア リンクを生成する

他の人が Web API のハイパーメディア リンクを生成する問題にどのように対処したか知りたいです。具体的には、ASP.NET Web API を使用しており、操作でハイパーメディア関連の型を返すか、リソース自体を返すか、パイプラインの後半でハイパーメディアを処理するかで迷っています。つまり、人々は次のようなことをする傾向がありますか?

またはもっと似たようなもの

そして、ハイパーメディア リンクを HttpOperationHandler またはカスタム フォーマッタなどに追加しますか?

アプローチが 2 に似ている場合、生成するリンクをどのように知るのでしょうか? すべての Order オブジェクトに対して生成される標準的なリンクのセットがあるだけですか? OrdersController のさまざまな操作を装飾する属性?

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

google-app-engine - Jersey リンクのサポートと Google App Engine の問題

Google App Engine で Jersey リンク サポートを使用できませんでした。アプリケーションにアクセスしようとすると、次の例外が発生します。

ドキュメントで指定されているように、これを web.xml の Jersey サーブレット セクションに配置します。

また、プロジェクトの WEB-INF/lib ディレクトリに jersey-server-linking-1.13.jar を追加します。

最初に el-api.jar を追加してから、juel-2.1.0.jar を WEB-INF/lib ディレクトリに追加しようとしましたが、まだこれらのエラーが発生します。

誰かがこれに対処する方法についてヒントをくれるかどうか知りたいです。Jersey リンク jar を使用しない場合、すべてが期待どおりに機能します。

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

symfony - JMSSerializerBundle を使用して適切なハイパーメディア形式を作成するには?

次のような XML 応答を作成したいとします。

次のようなドメイン モデルがあるとします。

そして、次のようなマネークラス:

さて、私の質問に。次のような応答を作成するのは非常に簡単です。

アノテーション、XML または YAML のいずれかを使用して、JMSSerializerBundle に製品オブジェクトをシリアライズする方法を指示します。ただし、xmlns:atomおよび<atom:link>エントリはエンティティによって指定されるべきではありません。これは、それがどのように、どこに配置されているかという概念を持たないためです。relなど、さまざまな属性を持つリンクをさらに想像することもできますedit
頭に浮かぶ 1 つの解決策は、特定のオブジェクトのシリアル化イベントをリッスンし、これらの属性とタグを適切に追加するサービスです。サービスは DI を使用してRequestRouterサービスなどを取得し、要求された形式に適した形式でこれらのリンクを生成できます。XML 応答の IE では、適切なタイプを次のように設定できます。application/media-format+xml、一方、json-response では、次のようなものを生成できます

現在、JMSSerializerBundle のドキュメントで@PreSerialize、 、 、およびの注釈を見つけまし@PostSerializeたが、シリアル化されているオブジェクトのメソッドしか呼び出せないようです。
これが達成できるかどうか/方法を知っている人はいますか? それとも、Twig などのテンプレート エンジンを使用して手動で XML 応答を作成する必要がありますか?

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

rest - Ember-data: 最高の Json 関連リソース

こんにちは、ember-data の関連リソースを操作するための最適なソリューションはどれか疑問に思っています。REST バックエンドを構築するため。

1) 埋め込みリソース

2) リソースの埋め込み ID

3) リンクされたリソース

HATEOAS のようにハイパーメディアを使用することは可能だと思いますか?

前もって感謝します

0 投票する
3 に答える
7967 参照

rest - Jersey で HAL を使用して HATEOAS を実装する

RESTful API を構築する際の重要なポイントの 1 つは HATEOAS です。現在、Jersey は非常に優れたリンク機能を提供しています (このリンクを参照してください)。しかし、 HAL 仕様のドラフトを見たことがありますが、よく考えられた作品のようです。

Jersey で HAL に準拠しやすい lib があれば興味があります。https://github.com/HalBuilderのようなドラフトで言及されている参照を見てきました。しかし、私は直接 POJO マーシャリングを使用していますが、それを Halbuilder と組み合わせる方法がわかりません。

では、Jersey に HAL を組み込んだライブラリはすでにあるのでしょうか? または、何らかのフィルターを使用して、生成された POJO を手動で強化できますか? はいの場合、誰かがこれを達成するために次にどこを見るべきか手がかりを教えてもらえますか?

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

api - RESt api:認証に基づいて変化するリソースとコンテンツの識別

私はHATEOAS/REStの原則に従ってAPIを設計しています。しかし、私はこの基本的なポイント、つまりリソー​​スの識別についてはよくわかりません。

ユーザーによって(このユーザーに)アップロードされたすべての画像を公開する次のURL:/imagesを想定します。

認証の目的でoauthアクセストークンを使用するとします。/imagesの内容はAuthorizationヘッダーによって異なります。

これは、リソースの概念の識別を壊しますか?

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

web-services - 純粋な HATEOAS vs あまりにも多くのサービス呼び出しを行う

UI を強化する RESTful Web サービスを構築しようとしています。純粋な HATEOAS の原則に従えば、コレクション内の個々のリソースの URI のみを公開する必要があります。ここで、親子関係があり、各親が 50 人ほどの子を持つことができ、UI では、親をクリックしたときにすべての子の部分データも表示する必要があるとします。

親で子 URI のみを公開すると、UI はこれを行うために 50 回の Web サービス呼び出しを行う必要があります。もう 1 つのアプローチは、URI だけでなく、親と子に関する部分的な情報を提供する別の API を用意することです。これは十分に一般的な問題だと確信しています。ここで適切なバランスはどれくらいですか? 落とし穴のいくつかは何ですか? 「URI のみ」のアプローチは、デザインの観点からはよりクリーンですが、これらすべてのサービス呼び出しのために、UI が非常に遅くなり、サーバーに多くの負荷がかかる可能性があります。したがって、他のアプローチがより実用的かもしれません。あなたの経験では、どちらが優れていますか?

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

rest - RESTfulHATEOASクライアントURL

HATEOAS設計のサーバー側(応答で状態URLを返す)を理解していると合理的に確信していますが、これらを受け入れるようにクライアントを設計する方法について少し混乱しています。

たとえば、//somehost.com/resource/1のリソースにアクセスします。これにより、リソースデータとリンクが提供されます。//somehost.com/resourceへのPOSTが返され、「新しい」アクションを示していると想定します。これで、そのURLにデータを投稿すると、新しいリソースが作成され、応答が提供されることがわかりましたが、そのデータを投稿するフォームはどこにありますか?//somehost.com/resource/1/newが/resourceにPOSTするフォームを提供する実装を見てきましたが、そのURL自体に動詞が含まれており、RESTに違反しているようです。

私の混乱は、RESTfulAPIとそれを使用するクライアントを同じアプリケーション内に実装していることにあると思います。

この種のことについて、ある種のベストプラクティスはありますか?

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

rest - REST APIでスーパータイプを表す最良の方法は何ですか?

../api/zoos動物園用のAPIがあり、特定の動物園の個々の動物にアクセスできるようになっているとしましょう../api/zoos/123/elephants/234。つまり、動物の種類ごとに明確に定義されたAPIがあります。
    ここで、スーパータイプ(抽象クラ​​スAnimal where class Elephant extends Animal)で../api/zoos/123/animals?type="mammal"&legs=4クエリを実行する場合、そのようなメタクエリの種類のAPIを公開するのは良い考えですか?
    このようなアプローチについて2回考えさせられるのは、スーパータイプのAPIは具体的なタイプ全体のメタクエリに実際に役立つ一方で、これは本質的に読み取り専用のクエリであり、拡張性の観点からも、スーパータイプの動物と具体的なタイプの間であると言えます。象には、哺乳類、FourLeggedなど、個別にクエリできる他の多くのタイプがあります。次に、読み取り専用APIをこれらにも公開する必要があるかどうか、または動物クエリにタイプパラメータがあるかどうかを呼び出す必要があります。それは仕事をします。提案してください。