問題タブ [hypermedia]

完全にハイパーメディア駆動型の API があるとします。消費者は、必要なリソースにたどり着くまで、次のハイパーメディアを介して 3 つのリソースをナビゲートする必要があります。クライアントがこれらのステップを一時的にキャッシュして、必要なリソースに直接移動できない理由はありますか?

REST の目的がクライアントとサーバーを切り離すことであることは知っていますが、5 つの Web リクエストが舞台裏で進行している場合、これらすべてが発生するのを待っていると、ユーザー エクスペリエンスが低下する可能性があります。

考えられる最悪のケースは、キャッシュされた URL が変更されることです。そのため、クライアントは再びエントリポイントから開始し、ステップをキャッシュします。

時系列チャートを表すためにIANAで既に定義されているメディア タイプを探していましたが、見つかりませんでした。

メディア タイプを知っている人はいますか? そうでない場合は、Collection+JSONやHALなどの一般的なコレクション メディア タイプを使用しますか?

と多対多の関係を設計する最良の方法は何hateoasですか? で定義された 2 つのクラス間に双方向の関係がありSetます。

私の問題は、あるリソースを別のリソースにバインドするPOST/メソッドです。PUT（関係づくり）

例：

最初の方法: リソース uris は

Awith id 1 とBwith id 2の間の関係を追加するには、 POSTon:/A/1/B/2または/B/2/A/1.

2 番目の方法:

コンテンツとして「B オブジェクト」を使用して、id A1 とBid 2の間の関係を追加するには:POST/A/1/B

どちらがより良い方法ですか、それともより良い解決策がありますか? 手伝ってくれてありがとう ：）

Golang でさまざまなカスタム タイプを取り込めるヘルパー関数を作成しようとしていますが、希望どおりに正確に実行する方法がわかりません。状況は次のとおりです (ちなみに、私は HAL プロトコルを実装する JSON オブジェクトを返す API を作成しています。これは、リソースと関係が単なる ID ではなくリンクとして返されることを意味します)。

アプリには、学生、校長、学校など、多数のモデルがあります。これらの各モデルには、同じものもあれば異なるものもある多くのフィールドがあります。理想的には、構造体のフィールドを反復処理し、構造体の別のフィールドを変更できる関数が必要です。大きな課題は、これらの構造体が Student、Principal、School などの型になる可能性があることです...

モデル:

次に、基本的にこれらの構造体のいずれかを取り、( を使用してreflect) フィールドを反復処理し、各フィールドで何かを実行できる関数が必要です。

取る関数を試しましたinterface{}が、問題は、フィールドにアクセスするには引数を型アサートする必要があることです。そして、それができたとしても、とにかく各タイプ/モデルに対して個別の関数を書く必要があります.:

最終的には、多少任意の構造体を受け取り、そこにある場合とない場合があるフィールドに対して操作を実行する関数を作成する方法を見つけようとしています。

2 つの異なる表現を持つことができるリソースをどのようにモデル化しますか。たとえば、1 つの表現が「シン」であり、その関連リソースのほとんどがリンクによってアクセス可能である場合があります。別の表現は、関連するリソースのほとんどが埋め込まれている「太い」ものかもしれません。リンクされたリソースを参照するために多くの呼び出しを行う必要があることを気にしないクライアントもあれば、すべてのデータを一度に取得したいクライアントもあります。

監督や俳優などに関連付けられた映画リソースを考えてみましょう。おそらく、そのシン バージョンには映画のタイトルしかなく、監督や俳優のリストなどのデータを取得するには、それらへの埋め込みリンク。おそらく、ファット バージョンには、内部にネストされたすべてのムービーが含まれており、監督のデータ、さまざまな俳優のデータなどが含まれます。

これをどのようにモデル化する必要がありますか？

いくつかのオプションが表示されます。

1. これら 2 つの表現は、実際には 2 つの異なるリソースであり、異なる URI が必要です。
2. application/vnd.movie.thin+jsonこれら 2 つの表現は実際には同じリソースであり、カスタム メディア タイプ (となど) を介して 2 つの表現から選択できますapplication/vnd.movie.fat+json。
3. これら 2 つの表現は実際には同じリソースであり、異なる表現の選択はクエリ パラメータ (例: /movies/1?view=thin) で行う必要があります。
4. 何か他の...

この種の API への適切なアプローチは何だと思いますか?

RESTful Web API ブックでは、著者は、プロファイルを公開し、リンク関係を認識するコンテンツ タイプを使用することを勧めています。Hydraによって拡張されたJSON-LDはこれらの要件に適合しているようで、新しい API の設計に使用したいと考えています。

現在、パフォーマンスの問題で立ち往生しています。オンラインの自転車店を経営していて、特定の自転車の車輪に関する情報を取得したいとします。

Hydra 仕様の場合、ホイールの詳細を取得するには 2 つのリクエストを送信する必要があるようです。最初のリクエストは、自転車自体に対するものです。

応答には、車輪のコレクションへの Hydra::Link が含まれています。

これで、wheels リソースに 2 番目のリクエストを送信して詳細を取得できます。

単一のリクエストを送信して、以下のようなレスポンスを取得することは有効ですか?

事前に: ハイパーメディアまたは Restfull の概念を誤解していたら申し訳ありません: 進行中の作業です...)

ハイパーメディアとヒドラ ( http://www.markus-lanthaler.com/hydra )を理解しようとしていますが、API を設計する前にクライアントに情報を返すことについていくつか質問があります。

www.myshop.com にウェブショップがあるとします。

ルートへの HTTP GET は、(たとえば) リンクとして表されるリソースのリストを返すことができます (json-ld ドキュメント内):

ヒドラに関する最初の質問です。ここにアクションを追加するにはどうすればよいですか? アプリケーションをロードする前に、クライアントが別のドキュメントをロードする必要があるようです。www.myshop.com/api から取得したドキュメントに潜在的なアクションが含まれていないことを意味します。

さらに進んで、productsは hydra:Link であると述べたので、クライアントは HTTP GET でそのリンクをたどって (対話して)、製品のリストを取得できます。それは次のようなリストになります:

ここで、クライアントは製品のリストを受け取ります (ページ化されたコレクションである可能性があります)。しかし、クライアントがそれをユーザーに表示したい場合は、 [製品 ID、価格、名前] (すべての製品のプロパティではない)を持つテーブルを考えてみましょう。

2番目の質問:クライアントが各製品のサーバーにリクエストを送信せずに、製品の詳細情報を取得するためのリンクを提供するにはどうすればよいですか?削除して、友人と共有するために 1 つ、バスケットに追加するために最後の 1 つ) ?

実際、ドキュメント自体にリンクが含まれていないため、ヒドラがどのように機能するのかを理解するのは困難ですか? Hal はこのアプローチを使用して、ドキュメント自体にリンクを作成していると思います (私が正しい場合)。

よろしく

Hypermedia をうまく活用した RESTful サービスを設計しようとしています。
できれば、サービスのすべての機能を探索できるように、ユーザー エージェントはルート URI のみを知っている必要があります。つまり、成熟度モデルの第 3 レベルにあることを望みます。

これで、ユーザー エージェントはいくつかのリソースを作成し、後でそれらを編集できるようになります。作成/編集時に、ユーザー エージェントは他のリソース/列挙にアクセスする必要があります。

fooリソース:

前述の要件を考慮して、次のパターンを考え出しました。

fooRootリソースを用意します。

fooリソースにfooWriterへのリンクを含めます。

fooリソース:

fooWriterは次のようになります。

要約すると、作成および編集できるすべてのリソースには、ライターリソースが関連付けられている可能性があります。writer
を GET することにより、ユーザー エージェントは非常に便利な方法でリソースを作成/編集できます。 ライターに埋め込まれたペイロードは、その宛先に POST され、ほら :)

また、リソースと新しいリソースのライターの両方へのリンクを保持するルートコンテナが必要です (上記の例のfooRootを参照)。

質問は...

...上記のパターンにはよく知られている名前がありますか? ...作成/編集時に隣接するリソースが必要であり、第 3 レベルの成熟度がまだ「保持」されている、作成/編集
の問題 を解決するより良い方法はありますか?

参考文献:

• ハイパーメディア規模
• リチャードソン成熟度モデル
• ハイパーメディアをうまく​​活用したREST API