問題タブ [hypermedia]

RAML ツールを使用して REST API モックを作成しました。JSON オブジェクト応答ハイパーメディア リンクで絶対パスを返すにはどうすればよいですか? 絶対パスを作成するためにサンプル JSON オブジェクトにbaseUri
を含める方法はありますか?

"/users/ff33c2a1-b877-4415-9e62-115b8239c787"現在、JSON オブジェクトに相対パスがあります。

そして実際には、ルートがbaseUri値から取得される絶対パスが必要です。

たとえば、パスは次のようにする必要があります"http://mocksvc.mulesoft.com/mocks/a2683439-a5dc-409c-801a-c771042970fb/mocks/31e46658-b4ce-4f40-cc91-c4fd50f7a2d8/v1/users/ff33c2a1-b877-4415-9e62-115b8239c787"

私は次のようなものを使ってみました:

"href": "{baseUri}/users/ff33c2a1-b877-4415-9e62-115b8239c787"

または引用符なし

"href": {baseUri}/users/ff33c2a1-b877-4415-9e62-115b8239c787

しかし、上記のどれもうまくいきませんでした。

RAML 0.8を使用しています。

私は現在、「Rest in practice」という本を読んでいます。ハイパーメディア、ハイパーメディア フォーマット、ハイパーメディア コントロール、ドメイン アプリケーション プロトコルという用語が理解できません。著者は、ドメイン固有のハイパーメディア形式の必要性を示唆していました。私はそれらをほとんど理解できませんでした。これらの用語をグーグル検索しましたが、正しい答えが見つかりませんでした。これらの用語と、 application/xml の代わりにドメイン固有のハイパーメディア形式が必要な理由を説明できる人はいますか?

HATEOAS REST API に基づく Web アプリケーションでの URL (および各 URL に関連する状態) の処理に関するアドバイスを探しています。より具体的には、

• Web アプリケーションの URL が REST API の URL と結合されないようにする方法
• 単一のビューで複数のリソースを処理する方法

しかし、最初にもう少しコンテキストを提供させてください。

ハイパーメディア制約を使用して、REST レイヤーの上に Angular Web アプリケーションを構築しています。(注: HATEOAS よりも単に「ハイパーメディア (制約)」という用語を使用することを好みます)。

ハイパーメディアの制約によって指示されるように、アプリケーションでいつでも使用可能なアクションとリンクは、REST API によって提供されます。そのため、Web アプリケーションには、「ルート」を除いて、REST API のハードコードされた URL を含めないでください (その概念が REST API に実際に存在すると仮定します)。

一方、Web アプリケーションの各ページはブックマーク可能である必要があります。そのため、ブラックボックス アプリケーションを作成することはできません (単一の URL と、URL を変更せずにすべての状態変更が SPA で処理される)。これは、Web アプリケーションにも独自の URL 空間があり、何らかの方法で REST API の URL 空間にマップする必要があることを意味します。これはすでにハイパーメディアのアイデアと矛盾しています。

Angular アプリケーションでは、アプリケーションの状態を処理するために UI Router を使用します。これを機能させる方法は次のとおりです。

• 状態のみを定義し、URL は定義しません
• 現在の Web アプリケーション URL を対応する REST API URL にマップし、その REST URL に対応するリソースの表現を取得して、コントローラー ($stateParams 内) に渡す $urlRouterProvider.otherwise ハンドラーを定義しました。
• コントローラーは、REST 呼び出し自体を (またはサービスを介して) 行った場合と同様に、データ (およびリンクとアクション) を表現で使用できます。

このアプローチにはいくつかの欠点があるため、これまでのところ非常に優れています (または実際にはそうではありません)。

• Web アプリケーションの URL は REST API の URL にマップされるため、両方の URL スペースが結合されます。これは、ハイパーメディア制約を使用する際の基本的な前提の 1 つと矛盾します。つまり、REST API の URL は、Web アプリケーションを変更せずに変更することはできません。
• $urlRouterProvider.otherwise ハンドラーでは、現在の Web アプリ URL の表現を取得します。しかし、場合によっては (UI ルーターのネストされた状態を使用して) 1 つのビューに 2 つのリソースがあります。たとえば、アイテムのリストと 1 つのアイテムの詳細です。ただし、URL は 1 つしかないため、アイテムの詳細の表現のみが取得され、アイテムのリストは空のままです。

そのため、2 つの URL スペースを処理するアプローチを改善する方法について、いくつかの提案をお待ちしております。REST API が Web アプリケーションの (利用可能な) 動作を決定し、Web アプリケーションにブックマーク可能な URL を保持するためのより良い方法はありますか? なぜなら今、私たちは完全に正しいとは思えないある種のハイブリッドなアプローチを持っているからです.

前もって感謝します。

よろしく、

リュック

2 つのリソース (ResourceA と ResourceB) を処理する 3 つの安らかなサービス (ServiceA、ServiceB、ServiceC) があります。リソースのメディア タイプは、application/hal+json です。

• ServiceA が ResourceA を生成します。
• ServiceB は ResourceA を消費し、ResourceB を生成します。
• ServiceC は、ServiceA から ResourceA を取得し、それを ServiceB にポストすることによって、ResourceB の生成を調整します。

このやり取りを整理するには、基本的に 2 つの方法があります。

1. ResourceA 直接仲介者としての ServiceC

   • ServiceC は ServiceA から完全な ResourceA を取得します
   • ServiceCはそれをServiceBに投稿します
   • ServiceB が ResourceB を返す

2. ResourceA 間接仲介者としての ServiceC

   • ServiceC は ServiceA の ResourceA へのリンクのみを取得します (たとえば、ResourceA の作成時に Content Location ヘッダーを介して)
   • ServiceC はこのリンクを ServiceB に投稿します (HAL メディア タイプのリンク rel を使用)
   • ServiceB は完全な ResourceA を ServiceA から直接取得します
   • ServiceB が ResourceB を返す

最初のアプローチは「古典的な」もののようですが、2番目のアプローチは、ResourceAの完全な送信が2つ（ServiceA -> ServiceC -> ServiceB）ではなく1つ（ServiceA -> ServiceB）であるため、安価です。理想的には、ResourceA が十分に大きい場合は、2 番目のアプローチが適しています。

2番目のアプローチを使用しても問題はありますか? これは「アンチパターン」と見なされますか、それとも何らかの方法で安全/推奨されませんか? より良い相互作用パターンはありますか?

REST API(HATEOAS) がある場合hypermedia-drivenは、応答にリンクを含めたり省略したりすることで、クライアントの動作を簡単に変更できます ( _links)。これにより、クライアントは、の現在の状態で可能な操作のアクセス許可をテストすることを完全に忘れることができますresource(操作へのリンクが存在するかどうか)。

さらに、現在のユーザーがプロパティを表示する権限を持っていない場合は、応答でプロパティを除外できます。

このようにして、承認は完全にサーバー上で行われます (そして、実行/表示できるアクションとプロパティを制御します)。

read-onlyしかし、財産を持ちたい場合はどうすればよいでしょうか? REST APIプロパティがリクエストに存在する場合 ( _POST_OR )、プロパティを無視しても問題ありません_PUT_。保存されないだけです。しかし、クライアントが書き込み専用プロパティと読み取り専用プロパティを区別して、ユーザーに適切なコントロールを表示するにはどうすればよいでしょうか (たとえば、無効な入力フィールドHTML)。

目標は、ユーザーのアクセス許可を決して持たないようにすることですclient requestが、完全にリソース主導型にすることclient/frontendです。

どんな助けでも大歓迎です:-)

私は REST API を設計しており、この特定のユース ケースでは、最善の方法とこのハイパーメディアがどのように見えるべきかを理解しようとしています。

シナリオは、発信者が、/persons?fields=lastName;filter=beginsWith=b姓が「b」で始まる人のリストを返したいという理由で電話をかけるというものです。

以下は、関連するハイパーメディアを含めて成形/表現する最善の方法を見つけようとしている JSON 応答を示しています。

人物のリストを表示できますが、name プロパティのみが表示されます。これは、各人物の部分的な表現であるためです。

次に、ここに HATEAOS を追加しようとしましたが、追加するのに最も役立つものと、実際に何を参照する必要があるのか​​ わかりません。

ここで返すグループ (リスト) 自体に href を提供できます。もしそうなら、どこで？私のようにルートオブジェクトに入れるのは意味がないと思います。ルートメタオブジェクトではなく、人々のリストを返すことが期待されているため、以下にあるものについては気分が良くありません。

また

この特定のインスタンスで HATEOS を実際に採用していない、または役に立たないと考える人はいますか?代わりに、ここに他のタイプの href リンクを提供する必要がありますか?

JSON - 返された人物オブジェクト (表現) のリスト

Golang 用のHydraドキュメント ジェネレーターに取り組んでいます。私はデモを例として使用してきましたが、ヒドラ用語のあいまいさについて疑問に思っていました。

• hydra:titleとはどう違いrdfs:labelますか？labelで使用されますが、 プロパティだけでvocab:Userなくとにもhydra:title使用されます。ResourceCollection
• Resourceと と言えばCollection、なぜこの ApiDocumentation で再記述されているのですか? それらはヒドラ/コアの一部であるべきではありませんか?
• 多くのプロパティには、同じ情報を含むhydra:title + hydra:descriptionとの両方があります。label + description何故ですか？無視して大丈夫ですか？

仕様でそれを見つけられなかった場合は事前にお詫びしますが、ハイパーメディア API に興味を持ったのはつい最近のことであり、多くの概念はまだ少し曖昧です。

POST/ PUT/リソースの HATEOAS リンクを表す最良の方法は何PATCHですか? これらの操作にはペイロードがありますが、HATEOAS リンクでペイロードを表すオプションはありません。これらは事前に決定されておらず、重い可能性があるためです。では、終点を指定して動作を指定するだけでよいのでしょうか。

HATEOAS // リンクを使用した JSON 応答のサンプルまたは例を大歓迎POSTしPUTますPATCH。