REST用語では、リソースと表現の違いは何ですか?


9

RESTについての理解は、サービス操作を状態の表現としてモデリングし、HTTPを使用してある状態から別の状態に遷移することを可能にします。リソースをサービスサイドの状態の表現として常に理解してきました。最近まで、コミュニティから尊敬されている賢い開発者/アーキテクトであることがわかっているJimmy Bogardによるこの記事を読みました。その投稿から特定のステートメントを引用するには

表現は少し異なります- リソースの現在の状態を示します(要求されたとき)。

これは私を混乱させました。このトピックについて一般的に受け入れられている意見は何ですか?


1
あなたはチェックしたいかもしれません:ここでどんなトピックを尋ねることができますか?。世論調査はProgrammers.SEのトピックではありません。
Adam Zuckerman

2
まあ、そのページにリストされているすべてのものは白黒で答えはありませんが、すべての意見があります。また、この質問が意見についてどうであるかわかりません。質問で「意見」という言葉を使ったからでしょうか。
Suhas、2016年

主に、はい。残念ながら(またはおそらく幸運にも)、「意見」、「ベストプラクティス」などの言葉は、「脳が存在するはずの空の共鳴空洞」と強く関連しています。遠くに行って、その後、走り去ります。言葉の定義を求める人々は、しばしば最悪の犯罪者です。解決しようとしている具体的な問題は何ですか?
ロバートハーベイ、

1
あなたの質問について言えば、リソースは単に「インターネット上でアドレスを持つ何か」であり、表現は「インターネット上のものを再提示する方法」です。ファイル、Webページ、JSONドキュメントのいずれかです。Word文書やスプレッドシートなど、特定の種類のファイルを使用できます。これらすべての場合において、表現とは、取得しているものです。「リソースの現在の状態」は、前回リソースを取得してから状況が変化した可能性があるという認識です。
Robert Harvey、

回答:


14

簡潔な答え

地図は領土ではありません。

より長い答え-他のRESTと同様に開始する場所はRoy Fieldingの論文です。特に5章。現在の質問については、セクション5.2.1が必要です。

RESTは4つのインターフェース制約によって定義されます。リソースの識別。表現によるリソースの操作; 自己記述的メッセージ; アプリケーション状態のエンジンとしてのハイパーメディア。

資源

RESTでの情報の主要な抽象化はリソースです。名前を付けることができる情報はすべてリソースにすることができます:ドキュメントまたは画像、一時的なサービス(たとえば、「ロサンゼルスの今日の天気」)、他のリソースのコレクション、非仮想オブジェクト(たとえば、人物)など。 。つまり、作成者のハイパーテキスト参照の対象となる可能性のある概念は、リソースの定義内に収まる必要があります。リソースは一連のエンティティへの概念的なマッピングであり、特定の時点でのマッピングに対応するエンティティではありません。

表現

RESTコンポーネントは、表現を使用してそのリソースの現在または意図された状態をキャプチャし、コンポーネント間でその表現を転送することにより、リソースに対してアクションを実行します。表現は、一連のバイトと、それらのバイトを記述する表現メタデータです。その他の一般的に使用されますが、正確ではない表現の名前には、ドキュメント、ファイル、HTTPメッセージエンティティ、インスタンス、バリアントなどがあります。

表現は、データ、データを説明するメタデータ、および場合によってはメタデータを説明するためのメタデータ(通常はメッセージの整合性を検証する目的で)で構成されます。

つまり、「ロサンゼルスの今日の天気」はリソースです。候補者の代表には次のものが含まれます。気象レーダーの視覚的表現、および予報の音声記録。


2

リソースとは、作業しているものです。たとえば、特定のランプを切り替えるためのAPIがある場合、リソースはランプ自体です。リソースは、物理的(例:ランプ、人物)または非物理的(例:記事、ロール、データベース内の行)で、リソースはプライマリ(例:残高)または派生(例:トランザクション)です。リソースは特定のエンティティ(このランプソケットにインストールされている5番目のランプなど)を参照することも、異なるエンティティにマップする役割を参照することもできます(現在インストールされているランプ、2008年8月5日にインストールされたランプなど)。または、複数のエンティティにマッピングできます(たとえば、家のすべてのランプ)。

リソースの表現は、サービスがリソースの状態を通信する方法です。たとえば、XML、JSONはランプの状態を表します。

REST APIでは、リソースは統一された識別子(URIなど)で識別されます。1つのリソースに複数の表現を含めることができます。HTTPREST APIでは、通常、HTTP Content-TypeおよびAcceptヘッダーで使用する表現を指定します。

クライアントサーバーアーキテクチャでの重要な実現の1つは、リソースをクライアントに持ち込むことができないこと、およびそのようにしようとするべきではないことです。代わりに、REST APIでは、リソースの表現を転送することにより、リソースをリモートで操作します。このように考えると、クライアントがランプを直接操作できるようにランプをFedExするのではなく、サービスがランプのXML / JSON / protobuf / CSV表現を作成し、クライアントが意図した操作の表現を送信します。次に、サービスはクライアントに代わってランプの実際の状態を操作するか、クライアントがランプの操作を実行する権限がない場合など、要求を拒否します。これは明らかな髪の毛のように見えるかもしれませんが、重要なのは、表現がリソース自体ではないため、


1

リソースは請求書である場合があります。

表現は、JSON形式またはXML形式の特定の時点での請求書です。後日、まったく同じ請求書が届く可能性があります。これは同じリソースになりますが、状態が異なる可能性があります(キャンセル、支払い済みなど)。

請求書の現在の状態(例:データベース内のすべての請求書データ)を取得し、他のデバイス(例:ブラウザ)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.