5

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 への適切なアプローチは何だと思いますか?

4

3 に答える 3

6

return-minimal パラメーターを指定して、 prefer ヘッダーを使用できます。

于 2014-06-20T04:07:29.190 に答える
2

これには Content-Type を使用することをお勧めします。パラメータも使用できます。

application/vnd.myapp; profile=light

于 2014-05-17T02:08:35.730 に答える
1

REST に関するフィールディングの論文では、リソース インターフェイスについて、IRI をエンティティ セットであるリソースにバインドする必要があることを説明しています。(これは SOAP とは異なります。通常、SOAP では IRI を操作にバインドするためです。)

Darrel Millerによると、パスは IRI で階層データを記述するためのものであり、クエリ文字列は非階層データを記述するためのものですが、API 内のリソースを識別するためにパスとクエリを一緒に使用します。

したがって、これらに基づいて、2 つのアプローチがあります。

  • より少ないプロパティを持つ同じエンティティを、独自の IRI を持つ新しいリソースにマップできると言えます。この場合、/movies/1?view=thinまたは で/movies/1/view:thin問題ありません。
    長所：
  • RDFによると 、プロパティにrdf:typeはrdf:Propertyとrdfs:Resourceどちらかがあり、REST にはセマンティック Web とリンクされたデータへの接続があります。
  • たとえば/movies/1/title、単一のプロパティの IRI を作成するのは一般的な方法です。したがって、単一のプロパティでこれを実行できる場合は、プロパティのコレクションでもこれを実行できます。
  • これは、エンティティのコレクションに既に使用しているmap reduceに似ています:/movies/recentなど... 唯一の違いは、エンティティのコレクションによってリストまたは順序付けられたセットを削減し、プロパティのコレクションによってマップを削減することです。/movies/recent/title最近の映画のタイトルを返すことができる: のように、両方を組み合わせて使用​​すると、はるかに興味深いものになります。

短所：

  • RDF では、すべてにrdf:typeof がrdfs:Resourceあり、REST は Web ドキュメントと同じ原則に従っていない可能性があります。

  • 単一のプロパティまたはプロパティ コレクションについては、論文のリソースと見なすことができるか、または見なすことができないかについては何も見つかりませんでしたが、テキストのそのセクションを誤ってスキップした可能性があります (かなり乾いたもの)...

  • より少ないプロパティを持つ同じエンティティは、同じリソースの異なる表現であると言えます。したがって、異なる IRI を持つべきではありません。この場合、優先ビューに関するデータをリクエストの別の場所に配置する必要があります。GET リクエストでは本体がなく、HTTP メソッドはこのようなものを格納するためのものではないため、配置できる場所は HTTP ヘッダーだけです。長期的なユーザー固有の設定により、サーバーまたはクライアントによって維持される Cookie に保存できます。短期間の設定により、多くのヘッダーで送信できます。ヘッダーによってcontent-type独自の MIME タイプを定義できますが、これはお勧めできません。1 つのアプリケーションだけでおそらく何百ものカスタム MIME タイプを使用するのは好きではないからです。ヘッダーによって、プロファイルcontent-typeを追加できますDoug Moscropが提案したように、MIMEタイプに。preferヘッダーによって、Darrel Millerが提案したreturn-minimal設定を使用できます。ヘッダーを使用しても理論上は同じことができますが、ページネーションによってのみ範囲ヘッダーに遭遇しました。 長所：range

  • これは確かに RESTful なアプローチです。

短所：

  • 既存の HTTP フレームワークは、これらの種類のヘッダー パラメータの抽出を常にサポートしているわけではないため、それを行うには独自の短いコードを記述する必要があります。
  • これらのヘッダーがクライアント側とサーバー側のキャッシュ メカニズムにどのように影響しているかについては何もわかりません。そのため、一部のブラウザーではサポートされていないものもあり、サーバーでは独自のキャッシュ実装を作成するか、ヘッダーをサポートするフレームワークを見つける必要があります。使用したい。

注：個人的には最初のアプローチを使用することを好みますが、それは単なる意見です。

Darrel Millerによると、REST では IRI の命名は実際にはカウントされません。

1 つの IRI が常に同じリソースを指していることを確認する必要があります。それだけです。IRI の命名の変更によってクライアントが壊れたくない場合は、クライアントが HATEOAS 制約を満たす必要があるため、IRI の構造はクライアント側ではカウントされません。これは、常にサーバーが IRI を構築し、クライアントがハイパーメディア応答で取得したこれらの IRI に従うことを意味します。これは、Web ブラウザーを使用してリンクをたどり、Web を閲覧するようなものです。REST を使用すると、ハイパーメディアにセマンティクスを追加して、クライアントに何が得られるかを説明できます。これは、schema.org、microdata、iana リンク リレーションなどの RDF ボキャブラリにすることができます (独自のアプリケーション固有のボキャブラリでも)...
したがって、Nice IRI の使用は REST では問題ではなく、サーバー側でルーティングを構成する場合にのみ問題になります。REST IRI で確認しなければならないことは、リソース (操作ではなく IRI マッピング) があり、IRI を使用してクライアントの状態を維持していないことです (たとえば、ユーザー ID、資格情報などの保存など)。

于 2014-05-13T03:25:56.750 に答える