0

メディアにアクセスするための RESTful リソースを設計しています。メディアは、ライブ ストリームまたはアーカイブ ストリームの場合があります。O'Rielly のテキスト「RESTful Web サービス」をガイドとして使用していますが、「プログラム可能な Web」と「人間の Web」を比較したリソースの表現に苦労しています。人間の Web リクエストについては、返したいと思いますHTML 表現 プログラム可能な Web リクエストの場合、XML を返したいと考えています。

GET http:// localhost :8080/stream - returns a list of streams

GET http:// localhost :8080/search?stream=abc - return a specific stream

正しい表現を返すことができるように、「人間の Web」からの要求と「プログラム可能な Web」からの要求を区別するにはどうすればよいですか?

O'Reilly のテキストは、2 つの別々のリソースの設計を示唆しているようです。PDFの24ページから、彼は次のように述べています。

同じツールを使用して、Web ページを取得して処理します。これら 2 つの URI: 1) http:// api。search.yahoo.com/WebSearchService/V1/webSearch?appid=restbook&query=jellyfish 2) http:// search.yahoo.com/search?p=jellyfish は、同じもののさまざまな形式を示しています。 1 つの URI は HTML を提供し、Web ブラウザーでの使用を目的としています。もう 1 つは XML を提供し、自動化されたクライアントによる使用を目的としています。

ヒューマン Web とプログラマブル Web を扱うための 2 つの別個のリソースは標準ですか、それとも代替手段はありますか? 考えを歓迎します。

4

2 に答える 2

0

公式の「フィールディング準拠」の答えは、ACCEPTSヘッダーを使用してコンテンツタイプネゴシエーションを使用することだと思います。http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htmにたくさんの良いものがあります

クライアントが text/html を要求する場合は、人間が読める html をフィードします。クライアントが text/xml を要求する場合は、xml をフィードします。ここでの秘訣は、実用的にはこれがクライアントによって常に十分にサポートされているとは限らないため、投稿した例のように、クエリ文字列またはリソース名マングリングを使用して多くのフォールバックが必要になることがよくあります.

個人的には、できる限りイデオロギーに従い、必要に応じて実用的にフォールバックを追加するようにしています。Acceptヘッダーの送信を適切に処理できないクライアントに遭遇するまで、プログラムまたは人間が消費するための別のリソースを作成しません。

于 2012-06-03T02:32:31.577 に答える
0

あなたの例は質問と一致しないので、両方に答えます。

あなたが与える例では、ストリームのリストと個々のストリームの2つの異なるリソースがあります。そのため、それらには別個の URI を割り当てる必要があります。クリーンで明白な代替手段がある場合は、クエリ文字列を使用しないことを強くお勧めします。

この場合は従来の ReST です。/stream/利用可能なストリームのリストで構成されるリソースです。このリストは、URI の人間またはコンピューター (またはできれば両方) のリストとして (text/html として) 提示する必要があります。

<ul>
  <li><a href="/stream/abc">ABC</a></li>
  ...
</ul>

これは、ストリーム リスト リソースのさまざまな表現を識別する方法という次の質問につながります。私が使用した手法は、コンテンツ ネゴシエーション、フォーマット クエリ パラメータ、RDFa の 3 つです。

RDFa は私の推奨する代替手段です。この場合、人間と機械が読み取り可能なコンテンツの両方をエンコードする表現は 1 つしかありません。単純なリストの場合、これは HTML への些細な変更です。

<ul>
  <li><a rev="rdfs:member" href="/stream/abc">ABC</a></li>
  ...
</ul>

データの純粋なマシン シリアル化が 1 つ以上ある場合、私が使用した 2 つの代替手段があります。一般に、両方同時に。

コンテンツ ネゴシエーションは、最も純粋で便利です。1 つの text/html と、別の application/xml または application/json を用意し、クライアントに選択させます。

これは、ブラウザー、コマンド ライン (curl/wget/etc)、またはスクリプトからマシンのバージョンをテストする場合には便利ではありません。そのため、フォーマット クエリ パラメータもサポートしたいと考えています。便宜上、Mime タイプを使用します。

リソースを同じコントローラ/サーブレット/etc で処理し、ファイルシステム/データベースなどから情報を取得し、MIME タイプ (コンテンツ ネガまたはフォーマット パラメータ) に基づいて適切なビューにディスパッチすることを好みます。画面。どちらの方法でも、同じリソースの異なる表現を扱っているため、サポートする代替アプローチが何であれ、それらが同じベース URI から確実に利用できるようにすることをお勧めします。

于 2012-06-03T03:52:42.397 に答える