RESTではRepresentational Stateの意味は何ですか？
2つの単語の正確な意味を理解するために、ネット全体を読んでいます。
代表州
私は疑問を持っています。これらの用語を誤解しています。私はこれについて良いアイデアを持っている人と理解を明確にしたいと思います。
私の理解では、サーバーにリソースがあります。 SO Restは、このリソースの何らかの表現状態をクライアントに転送することを意味します。
サーバーにリソースxがある場合、リソースxの表現状態yを作成でき、それをWeb上で転送できるのは、RESTの意味、これが正しいか、正しい意味ですか誰かがこれを説明してくれます。
代表国家の移転とは、「代表」の移転を指します。リソースの「表現」を使用して、サーバー上に存在するリソース状態をクライアント上のアプリケーション状態に転送しています。
RESTはステートレスですが、その名前にはステート転送があります。誰にとっても少し混乱します。
ステートレス
ブラウザでWebページを開くと、サービスコンシューマとして機能し、wwwサーバーがWebページを提供するサービスプロバイダとして機能します。通常の接続の場合、クライアントとサーバーの両方がハンドシェイクを実行し、セッションを開始します（TCP接続）と呼ばれます）。
その後、サーバーとクライアントの動作に基づいて、状態はESTABLISHED、IDLE、TIMEOUTなどのいずれかに変わります。しかし、RESTでは、ステートレスであるHTTPプロトコルを使用しています。つまり、サーバーはセッション情報を保存しません。クライアント。クライアントは、サーバーがサービスを受けるために必要なすべての詳細を送信する責任があります。つまり、URI http://somedomain:8080/senthil/services/page1サーバーから、page1を完全に提供するのに十分なクライアントの詳細があります。
状態転送
同じ例を使用して、サーバー上の画像ファイル（リソース）を表示するURLを使用してWebページを開くと、wwwサーバーは何らかの形式で画像（クライアント）を表示します。つまり、リソース（画像ファイルの表現） ）。
このプロセスでは、サーバーの定数resource state（サーバーに保存されている画像ファイルの状態）データベース）は、クライアントに対して）アプリケーション状態のわかりやすい形式で表されます。そのため、リソースの状態はクライアントに関して一定のままであり、リソースの表現のみが変更され、アプリケーションの状態が変更されます。
最後に、サーバーとクライアントの両方の状態を暗黙的に変更するリソースの表現（クライアントへの画像の表示方法）はRESTと呼ばれます。
すべてのオブジェクトには状態（データ）と動作（メソッド）があります。特定の時点でサーバー上のオブジェクトの状態をクライアントに転送するには、JSONやxmlなどの何らかの形式の表現が必要です。
RESTは、オブジェクトの現在の状態の表現を作成し、その表現をネットワーク経由で転送することです。
REST建築スタイルについての懸念に関する質問全体は、著者のRoy Fieldingが彼の論文で一連の建築ハイパーテキストまたはハイパーメディアパラダイムに基づいてアーキテクチャを構築するための原則。
このパラダイムは、この重要なトピックを理解するための中心的な鍵だと思います。
Roy Fieldingによって提案されたクライアントサーバーアプリケーションのアーキテクチャを整理するスタイルの背後には、アプリケーションの状態遷移を管理するための一種のエンジンによって構成される、現代のクライアントサーバーアプリケーションの特定のアイデアがあると思います。無限。
このビジョンでは、Ipertext\Ipermediaはフィールディングによって提案された建築スタイル全体の中心であり、このパラダイムが機能することを可能にする重要な概念は「表現（状態）転送」です。
「表象」は「状態」に関する概念ではなく、「移転」に関する概念を指していると思いますが、つまり、それは（代表的なタイプの）代表的なものへの移転であり、それは私の意見では、「代表的な国家移転」という名前の主な原因です。
だから、安らかなアプリケーションを設計するために、最初にコンポーネントのウェブに基づくアーキテクチャを設計します。各コンポーネントは、クライアントサーバーレイヤードアーキテクチャモデルで他のコンポーネントと通信し、それぞれを送信しますそれらの状態の表現
したがって、このアーキテクチャの最初のクライアントであるフロントエンドは、「プライベート」APIではなく、統一された一貫性のあるインターフェイスで承認を呼び出すコンポーネントによって送信された状態の表現を示す状態を遷移します。
このようなタイプのアプリケーションは、著者の心では、潜在的に無限状態に拡張可能です。なぜなら、その状態はプライベートAPIに依存せず、ユニボックに依存しているからです。このアーキテクチャのすべてのエージェント、その状態の遷移を管理するいくつかの動詞、および合意された共有表現転送システム、またはプラスで共有される識別子システム（URIとして）、またはプラス。
この遷移は、コンポーネントのクライアントサーバーが使用するステートレス通信プロトコルに属する「パブリック」APIを構成する動詞を介して、呼び出されたサーバーコンポーネントへのその表現の通信で終了します。
このような方法で、このクライアントとサーバーのコンポーネントの対話は、ステートレスプロトコルを使用するコンポーネントの状態の表現を交換（転送、通信）することにあります。
そして、これらのすべてのアーキテクチャを無限に拡張することを可能にするコアコンセプトは、アーキテクチャを支持する代表的な転送です。
TL; DR
Representational state transferまたは単にRESTは、相互運用性を高めるために、明確に定義された形式でデータを交換するための用語です。クライアントからサーバーへの特定の制約の適用により、前者はより堅牢で、後者は変更に対してより柔軟です。
リソース表現は、リソースの現在の状態から、明確に定義された構文および構造のメディアタイプにマッピングを適用した結果です。したがって、リソースの状態を要求された表現（=構文と構造）に変換するためにメディアタイプに同意するプロセスを定義する content-negotiation と高度に結合されます。
RESTは、分散システムでクライアントをサーバー/ APIから分離する手法と見なすことができます。これにより、クライアント側の実装を中断することなく、サーバー側で必要に応じて構造を進化および変更できます。
このような強力なメリットを得るには、無料のものがほとんどないため、いくつかの前提条件を整える必要があります。ここでのフィールディングは、彼が よく知られているブログ投稿 でさらに明確にした（そして説明した）いくつかの制約を定義しました。クライアントがRESTアプローチに従わなければ、サーバーはそのような自由を達成できません。また、サーバーがクライアントをサポートしていない場合、クライアントはさらなる可能性を動的に探索できません。要するに、両方の側が同じ原則に従う必要がありますアプローチが厳しくない場合、サーバーとクライアント間の直接的な結合が維持され、サーバーがこれから変更される場合に障害につながります。
しかし、デカップリングは実際にどのように達成されますか？
まず、サーバーは、クライアントが使用できるURIを含めることにより、そのタスクに従うクライアントをサポートする必要があります。クライアントが現在の状態からクライアントが呼び出すことができるすべてのURIをサーバーに提供させることにより、クライアントがAPIとURIの構造を事前に知っている必要がなくなります。
第二に、クライアントにURIを解釈させる代わりに、サーバーはリンク関係名と組み合わせてURIを返す必要があります。つまり、http://server.org/api/ordersのようなURIを使用する（および解釈する）クライアントの代わりに、new-orderのようなリンク関係を使用する必要があります。サーバーが上記のURIをhttp://server.org/api/new-ordersに変更した場合、何らかの理由でリンクリレーション名を使用するクライアントは引き続きタスクを実行できますが、URIを直接使用するクライアントは続行する前に更新が必要になります。
私の知る限り、そのようなリンク関係名を定義して文書化する必要がある標準はまだありません。コレクションリンクの場合、self、prev、next、first、およびlastなどの関係名のセマンティクスは、何か重要な意味を持っているようですorderやproduct-xyzのようなよりドメイン固有ではないかもしれません。そのようなセマンティクスは、特別なメディアタイプまたは新しい標準のいずれかで記述できます。
これまでのところ、これらのポイントはHATEOASの制約に取り組んでいますが、残念ながらそれだけではありません。フィールディングスのブログ投稿によると：
A REST APIは、リソースの表現とアプリケーションの状態の駆動に使用されるメディアタイプの定義、または拡張リレーション名やハイパーテキスト対応マークの定義に、記述的な努力のほとんどすべてを費やす必要があります-既存の標準メディアタイプの場合。
フィールディングのさらなるコメント：
A REST APIは、クライアントにとって重要な「型付き」リソースを持つことはできません。仕様作成者は、インターフェースの背後のサーバー実装を記述するためにリソース型を使用できますが、クライアント：クライアントにとって重要なタイプは、現在の表現のメディアタイプと標準化された関係名のみです。
typed resource は、クライアントがコンテンツを前提とするリソースです。つまりリンク関係名userを持つURI http://server.org/api/user/sam+sampleを受け取ったクライアントは、そのリソースに属するデータが人を記述することを決定するため、リソースデータのapplication/json表現をマーシャリングしようとする場合がありますPersonオブジェクト。
型付きリソースの問題は、クライアントがそのようなリソースに含まれるデータに関する特定の事前に割り当てられた仮定または知識、つまり、サーバーごとに異なるユーザーリソースを持っていることです。 1つのサーバーがnameプロパティとしてユーザー名を公開する場合もありますが、他のサーバーはfirstNameおよびlastNameを使用する場合があります。さらに、サーバーがロジックを変更した場合、クライアントは一定の可能性で破損する可能性があります。このカップリングメディアタイプに対抗するには、代わりに使用する必要があります。
メディア形式は、人間が読める形式のテキスト記述であり、使用される構文と、その形式で交換されるドキュメントに含まれる利用可能な要素の構造とセマンティクスを定義します。したがって、REST Architecturモデルは、相互運用性を高めるために 確立済み またはカスタムメディアタイプを使用する必要があります。クライアントとサーバーを直接結合する代わりに、両方とも実際にメディアタイプに結合します。そのようなメディアタイプのサポートは、既存のライブラリをロードするか、仕様をゼロから実装することで提供できます。
クライアントとサーバーは コンテンツネゴシエーション を使用して、リソースの現在の状態を交換するために、両方の当事者が理解する共通のメディアタイプ形式に同意する必要があります。コンテンツネゴシエーションは、HTTP Acceptヘッダー（および/またはその兄弟の1つ）を提供することによって達成されます。これは、リクエスト内で、またはサーバーがContent-Type HTTP応答ヘッダーを含む要求された形式のうち、実際に使用されたメディアタイプ表現をクライアントに通知するか、406失敗応答を返します。
上記の人の例では、クライアントは次のコンテンツを含むHTTP Acceptヘッダーをサーバーに送信できます：application/vcard+json, application/hal+json;q=0.6, application/json;q=0.1は、次のように定義された構文と構造でリソースの状態を返すようサーバーに要求しますリストされたメディアタイプの1つ。さらに、クライアントはapplication/vcard+jsonメディアタイプの記述の仕様に従ってフォーマットされた状態を受信することを好み、サーバーができない場合は従来のjson構文よりもhal + jsonを優先することを指定します。サーバーは、現在のリソースの状態を要求された形式のいずれかにマッピングするか、要求されたメディアタイプがすべて不明であるか、状態がそのような構造またはデフォルトに変換できない場合、適切な406失敗メッセージで応答しますクライアントがサポートする表現。
要約すると、RESTは、明確に定義されたメディアタイプに依存して高い相互運用性を実現し、コンテンツネゴシエーションやHATEOASなどの機能を使用してサーバーからクライアントを切り離すために使用される技術です。サーバーは、変更が有効になった後にクライアントが対話することを恐れることなく、進化して変更できるという利点を得ることができます。
標準化された意味のあるリンク関係名、カスタムドメイン依存のメディアタイプ、および状態をメディアタイプの適切な表現に変換するマッピングプロセスなどの特定のものを最初に設定する必要があります。これは重要ではないタスクTBHです。
REPRESENTATIONAL STATE TRANSFERの意味はRESTです
RESTfulはDIRECT VERBをサーバーに入れました
実際の検討例では、VERBに入れられる値は一般的にHTTP GETおよびPOSTを持ちます
SOAP（非常に複雑です！）
回答に満足できない場合は、より詳細な質問を提供してください
RESTには多くの議論のトピックがあり、多くのブログや本のトピックです
状態図を想像してください-次のようになります。
これが一連のWebページである場合、学生のUndergraduateランディングページから開始します。図に従って、「次へ」リンクをクリックすると、Freshmanページに移動します-学生が卒業したと仮定します。 「次へ」を複数回クリックすると、最後のページに移動します。
もちろん、「ホーム」のような他のトランジションがあり、デフォルトのページにジャンプすることができます。
Webサイトの表示状態は、サーバーがこの関連付けを内部的に実装する方法、つまり内部状態とは何の関係もありません。複数のデータベース、サーバーなどが関係する場合があります。学生が卒業し、そのステータスが他の方法で更新された可能性があります。クライアントはこれらの詳細を認識していませんが、人間（またはマシン）の消費に対して一貫した可視状態（セット）を取得することを常に期待できます。
別の例：このページを見ていると、StackOverFlow Web階層内の特定の識別可能な再現可能な「場所」にいます。
したがって、RESTful Stateはナビゲーションを扱います。