問題タブ [hal-json]

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 投票する
1 に答える
2324 参照

collections - 埋め込み HAL リソース コレクションに self href がありません

self hrefクライアント側の HAL リソースからを使用して、CRUD 操作の正しいパスを見つけます。単一(トン)のリソースでは、これは正常に機能しています(以下のアドレスリソースを参照してください。_links含まself hrefれている は埋め込みリソースに含まれています)が、コレクションになると、これは別の話です. _linksコレクションが にある場合、コレクションの はレンダリングされません_embedded

最初の子から URL を読み取ることで、この問題を回避しました。しかし、これでは十分ではありません。コレクションが空の場合、そのようなURLを抽出する可能性がない空の配列しかありません。コレクションに新しいアイテムを作成したい場合、 fromPOSTを読み取ることで、クライアントがデータの送信先を知っていることを望みます。を次のようにコレクションに含めることをお勧めします。self href_links_links

これで、ここで自己 href にアクセスできます。

編集(1年後)

最後に、埋め込みリソースのリンクを常に親リソースに追加することでこれを解決しました。したがって、上記の例では、応答オブジェクトは次のようになります。

そのため、リソースを埋め込んでいるかどうかに関係なく、それらがどこにあるかを常に把握しています。連絡先コレクションについては、配列内のコレクション エンドポイントへのリンク_linksと、連絡先自体へのリンクを_embedded.

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

rest - REST/HATEOAS API へのエントリ ポイントですか?

API の設計を開始し、REST/HATEOAS に準拠させることにしました。API のエントリ ポイントは何にする必要がありますか?

一般的なもののように思えますが、実際には取得するためのリソースがないため、GET /を使用する方が論理的に理にかなっている可能性があります。OPTIONS //

ここでは、JSON のHAL構文をハイパーメディア形式として使用して、両方の例を示しました。

得る /

リクエスト:

応答:

オプション /

リクエスト:

応答:

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

json - HTTP ロケーション ヘッダーが POST 要求/201 (Created) 応答に対してのみ設定されるのはなぜですか?

ちょっと 3xx レスポンスを無視して、なぜ HTTP ロケーション ヘッダーが POST リクエスト/201 (Created) レスポンスと組み合わせてのみ使用されるのか疑問に思います。

RFC 2616 仕様から:

201 (Created) 応答の場合、Location はリクエストによって作成された新しいリソースの場所です。

これは広くサポートされている動作ですが、他の HTTP メソッドで使用しないのはなぜでしょうか? 例として、 JSON API 仕様を取り上げます。

JSON ペイロード内の現在のリソースの自己参照リンクを定義します ( RESTful API では珍しくありません)。このリンクはすべてのペイロードに含まれています。仕様では、 POST を介して新しいドキュメントを作成する場合は HTTP ロケーションヘッダーを含める必要があり、その値はペイロード内の自己参照リンクと同じであると記載されていますが、これはPOST にのみ必要です。HTTP ロケーション ヘッダーだけを使用できるのに、自己参照リンクのカスタムフォーマットにわざわざこだわる必要はありません。

注: これは JSON API に固有のものではありません。HALJSON ハイパースキーマ、またはその他の標準でも同じです。

注 2: HTTP リンク ヘッダーと同じであるため、HTTP ロケーション ヘッダーに固有のものではありません。JSON API を見るとわかるように、HAL と JSON ハイパースキーマは、自己参照リンクの規則を定義するだけでなく、関連するリソースやリソースの可能なアクションに関する情報を表現します。しかし、それらはすべて HTTP リンク ヘッダーを使用できたようです。(HTTP ロケーション ヘッダーを使用したくない場合は、自己参照リンクを HTTP リンク ヘッダーに入れることもできます。)

怒鳴りたくはありませんが、ある種の「車輪の再発明」のようです。また、非常に制限されているようです: HTTP ロケーション/リンク ヘッダーのみを使用する場合、HTTP 受け入れヘッダーで JSON、XML、またはその他を要求しても問題はなく、リソースに関する有用なメタ情報を取得できます。 JSON API、HAL、または JSON ハイパースキーマを使用する場合、HEAD リクエストにはリンクが含まれません。

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

rest - JSON-LD での HAL ボキャブの使用

JSON-LD で HAL の概念を使用する方法はありますか?

現在の jsonld ドキュメントがあります。

しかし、 にofなどhrefがあることを定義する方法がわかりません...@type@id

RDF(S) に基づいて HAL ボキャブを定義し、それを何らかの方法で jsonld ドキュメントの @context にインポートする方法はありますか?
(リンク関係、HTTP メソッド、受け入れられたメディア タイプ、言語、IRI テンプレート、入力フィールドなど、さまざまなプロパティを使用してハイパーリンクを記述しようとしています。そのため、@idリンクを記述するにはタイプだけでは不十分です。)