1

これはRESTの説明を求める質問のフォローアップです。

私の回答に対するコメントからわかるように、リソースの最適なメディア表現について、Darrel Millerとちょっとした議論がありました。この質問に至った電子メールでの議論がさらにありました。

Darrel と私の REST に対する理解の主な違いは、データのセマンティックが REST API の一部であるかどうかです。

Darrel は (彼の言葉の私の解釈 :-))、データのセマンティックは REST API の重要な部分であり、そのため、選択されたメディア表現はそれを反映する必要があると考えています。したがって、適切な REST API は次のいずれかを選択する必要があります。

  • 多くのクライアントがリソースのセマンティックをネイティブに理解できるように、データを表す ATOM のようなよく知られたメディア。
  • application/vdn.mycomany.mymedia のようなアプリ固有のメディア タイプであり、クライアントがこのメディア タイプを理解してリソース データを消費できることを期待します。Application/xml は、メディア タイプのセマンティックを表していないため、適切なリソース表現ではありませんが、クライアントはセマンティックについて詳しく知る必要があります。

一方、REST API は実際のデータ表現とは別のレイヤーであると考えています。API によって公開されるメディア タイプは、リソース データを転送する単なるコンテナーです。データの実際のセマンティックは個別に扱われます。したがって、データを理解していないクライアントでも、REST API を使用できます。Application/xml は、スキーマを理解するクライアントの密結合を可能にすると同時に、スキーマを理解しないクライアントがリソースの基本的な処理を実行できるようにするため、非常に優れたデータ表現です。

したがって、問題は、REST API のデータ セマンティック部分ですか? データのセマンティックを実際に表すリソース表現のメディア タイプのみを選択する必要がありますか?

人々が回答にいくつかの引用を投稿してくれれば、できればロイの男自身から引用していただければ幸いです。:-)

4

3 に答える 3

4

最初から始めましょう。メディア タイプは、次に何をすべきかを決定するために使用できる形式をクライアントに提供するために存在します。HTML ページがなければ、ブラウザーにはリンク先がありません。HTML レンダラーがないと、ブラウザーはページをレンダリングできず、何をすべきかわかりません。

メディア タイプがないと、クライアントはバイト ストリームで何かできるかどうかわかりません。実際、クライアントが application/xml を指定するヘッダーを受信すると、xml パーサーを取得する以外に何をすべきかがわかりません。

したがって、実際の問題は、クライアントが HTTP メッセージに基づいてメッセージの内部を確認せずに決定を下せるかどうか、または何をすべきかを知るためにメッセージの内部を覗き見する必要があるかどうか (または、まずメッセージを解析する必要があるかどうか) です。行う。

メディア タイプがないということは、クライアントが追加のピーク作業を行うか、さらに悪いことにエンティティ本体自体を処理してから、レンダリングまたは処理の決定を行う必要があることを意味します。処理するフォーマットごとに多くのカスタム動作を追加する必要があり、その過程で結合が少し失われます。

仲介者が本文を検査せずにリクエストを処理できる必要があることも http の基本であり、application/xml にも問題があります。

メディア タイプのセマンティクスが API の一部であるか、API の一部ではないかというと、API を構成するものは何ですか?

クライアントの観点からは、API はありません。クライアントが次に何をすべきかを決定できるようにする初期表現があります。メディア タイプは、クライアントが「API」をナビゲートするために必要な情報を取得する場所であり、表現のない API はあり得ません。

さらに、クライアントは、ブートストラップの場所、HTTP プロトコル、およびメディア タイプの 3 つの知識しか持たない必要があります。1 つ目は単なる URI であり、続行するために必要な表現の場所を超えて多くを伝えません。2 つ目は、すでに非常に明確なセマンティクスを持っています。3 つ目は、クライアントとの契約であるため、コントロールできるものです。

そのコントラクトは、何かをしたいときはいつでも、その何かにはセマンティクスがあることを示しています: 顧客を追加するには、POST を使用して application/vnd.acme.customer+xml を /customers に送信します。

したがって、私の答えは次のとおりです。REST アーキテクチャの設計は、リソース モデリング (概念レベルでの) とメディア タイプの構築という 2 つのステップに依存します。それ以外の場合は、間違っている可能性があります。

于 2009-02-22T14:46:08.100 に答える
0

application/xml が「自己記述型」の制約を満たさない理由の詳細については、Mark Ba​​ker のこの一連のスライドを参照してください。また、彼のブログで多数の投稿を読むことができます。これには、application/xml + 名前空間がメディア タイプと同等ではない理由を彼が説明し続けているものも含まれます。

于 2009-02-22T14:20:34.793 に答える
0

私はそれについて過度に衒学的である必要があるとは思いません。リソースは複数の表現を公開できます。それぞれに独自のセマンティクスがあります (さらには複数の次元のセマンティクスもあります)。1 つの表現が特定のユース ケースで必要なセマンティクスを提供しない場合は、提供するものを公開します。

したがって、データを理解していないクライアントでも、REST API を使用できます。

何が適切な表現をするか、またはしないかについての良いリトマス試験紙であるかどうかはわかりません。ドキュメントを消費できるが、それを十分に理解していないクライアントは何の役に立つでしょうか? 「リソースの基本的な処理」が application/xml を 1 と 0 の任意のブロブよりも優れた選択肢にする方法を理解していないと思いますか?

あなたが参照を求めたので、これはRoy Fielding の記事で、彼はソーシャル ネットワーク グラフのビットマップ表現を「提案」しています。確かにマシンにこれらのビットマップを表示させることはできますが、基礎となるソーシャル ネットワーク グラフを理解していなければ、それが何の役に立つのでしょうか? 表現を application/xml に変更すると、素朴なクライアントがビットマップに含まれていない追加の意味を抽出できるようになりますか? いいえ。

于 2009-02-22T05:42:20.903 に答える