問題タブ [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.
collections - 埋め込み HAL リソース コレクションに self href がありません
self
href
クライアント側の HAL リソースからを使用して、CRUD 操作の正しいパスを見つけます。単一(トン)のリソースでは、これは正常に機能しています(以下のアドレスリソースを参照してください。_links
含まself
href
れている は埋め込みリソースに含まれています)が、コレクションになると、これは別の話です. _links
コレクションが にある場合、コレクションの はレンダリングされません_embedded
。
最初の子から URL を読み取ることで、この問題を回避しました。しかし、これでは十分ではありません。コレクションが空の場合、そのようなURLを抽出する可能性がない空の配列しかありません。コレクションに新しいアイテムを作成したい場合、 fromPOST
を読み取ることで、クライアントがデータの送信先を知っていることを望みます。を次のようにコレクションに含めることをお勧めします。self
href
_links
_links
これで、ここで自己 href にアクセスできます。
編集(1年後)
最後に、埋め込みリソースのリンクを常に親リソースに追加することでこれを解決しました。したがって、上記の例では、応答オブジェクトは次のようになります。
そのため、リソースを埋め込んでいるかどうかに関係なく、それらがどこにあるかを常に把握しています。連絡先コレクションについては、配列内のコレクション エンドポイントへのリンク_links
と、連絡先自体へのリンクを_embedded
.
rest - REST/HATEOAS API へのエントリ ポイントですか?
API の設計を開始し、REST/HATEOAS に準拠させることにしました。API のエントリ ポイントは何にする必要がありますか?
一般的なもののように思えますが、実際には取得するためのリソースがないため、GET /
を使用する方が論理的に理にかなっている可能性があります。OPTIONS /
/
ここでは、JSON のHAL構文をハイパーメディア形式として使用して、両方の例を示しました。
得る /
リクエスト:
応答:
オプション /
リクエスト:
応答:
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 に固有のものではありません。HAL、JSON ハイパースキーマ、またはその他の標準でも同じです。
注 2: HTTP リンク ヘッダーと同じであるため、HTTP ロケーション ヘッダーに固有のものではありません。JSON API を見るとわかるように、HAL と JSON ハイパースキーマは、自己参照リンクの規則を定義するだけでなく、関連するリソースやリソースの可能なアクションに関する情報を表現します。しかし、それらはすべて HTTP リンク ヘッダーを使用できたようです。(HTTP ロケーション ヘッダーを使用したくない場合は、自己参照リンクを HTTP リンク ヘッダーに入れることもできます。)
怒鳴りたくはありませんが、ある種の「車輪の再発明」のようです。また、非常に制限されているようです: HTTP ロケーション/リンク ヘッダーのみを使用する場合、HTTP 受け入れヘッダーで JSON、XML、またはその他を要求しても問題はなく、リソースに関する有用なメタ情報を取得できます。 JSON API、HAL、または JSON ハイパースキーマを使用する場合、HEAD リクエストにはリンクが含まれません。
rest - JSON-LD での HAL ボキャブの使用
JSON-LD で HAL の概念を使用する方法はありますか?
現在の jsonld ドキュメントがあります。
しかし、 にofなどhref
があることを定義する方法がわかりません...@type
@id
RDF(S) に基づいて HAL ボキャブを定義し、それを何らかの方法で jsonld ドキュメントの @context にインポートする方法はありますか?
(リンク関係、HTTP メソッド、受け入れられたメディア タイプ、言語、IRI テンプレート、入力フィールドなど、さまざまなプロパティを使用してハイパーリンクを記述しようとしています。そのため、@id
リンクを記述するにはタイプだけでは不十分です。)