HTTPとRESTの違いは何ですか？
RESTとSOAPの違いについて多くを読んだ後、RESTはHTTPの単なる別のWordであるという印象を受けました。誰かがRESTがHTTPに追加する機能を説明できますか？
注意：RESTとSOAPの比較を探していません。
更新：ご回答いただきありがとうございます。これで、RESTはHTTPの使用方法に関する一連のルールにすぎないことが明らかになりました。したがって、 これらの規則の利点は何ですか に関するフォローアップを投稿しました。
注意：RESTの意味を理解しました。 as Emil Ivanov 備考、RESTはHTTPを本来の意味で使用することを意味します。しかし、これがそれ自体の用語に値するかどうかはわかりません。確かに、それについての誇大広告は得られません。
いいえ、RESTは方法ですHTTPはused.
今日は、HTTPプロトコルのごく一部のメソッド、つまりGETとPOSTのみを使用しています。それを行うREST方法は、プロトコルのすべてのメソッドを使用することです。
たとえば、RESTは、DELETEを使用してURIの背後にあるドキュメント（ファイル、状態など）を消去するよう指示しますが、HTTPでは、...product/?delete_id=22のようなGETまたはPOSTクエリを誤用します。
HTTPは通信に使用されるプロトコルで、通常はインターネットリソースまたはWebブラウザークライアントを使用するアプリケーションとの通信に使用されます。
RESTは、アプリケーションの設計時に使用する主な概念がリソースであることを意味します。実行するアクションごとに、通常はCRUD操作のみを行うリソースを定義する必要があります。これは単純なタスクです。そのため、HTTPプロトコルで使用される4つの動詞を4つのCRUD操作に対して使用すると非常に便利です（読み取り用に取得、POSTはCREATE、PUTはUPDATE、DELETEはDELETE）。これは、ユーザーの呼び出しの結果として実行する一連のアクションがあるRPC（リモートプロシージャコール）の古い概念とは異なります。たとえば、投稿のようにFacebookを説明する方法について考えている場合、RPCを使用してAddLikeToPostおよびRemoveLikeFromPostというサービスを作成し、FB投稿に関連する他のすべてのサービスと一緒に管理できます。したがって、特別な作成は不要です。 Likeのオブジェクト。 RESTを使用すると、削除機能と作成機能で個別に管理されるLikeオブジェクトが作成されます。また、データベース内の別のエンティティを記述することも意味します。それは小さな違いのように見えるかもしれませんが、そのように動作することは通常、はるかに単純なコードとはるかに単純なアプリケーションをもたらします。その設計では、アプリのロジックの大部分はオブジェクトの構造（モデル）から明らかであり、RPCとは異なり、通常は多くのロジックを明示的に追加する必要があります。
rESTfulアプリケーションの設計は、複雑なものを簡単な方法で記述する必要があるため、通常ははるかに困難です。 CRUD関数のみを使用してすべての機能を説明するのは難しいですが、それを行うと、あなたの人生はずっと簡単になり、より短いメソッドを書くことに気付くでしょう。
存在するもう1つの制約RESTアーキテクチャは、クライアント（ステートレス）と通信するときにセッションコンテキストを使用しないことです。つまり、すべての情報はクライアントが誰であり、何が欲しいかをWebメッセージで渡す必要があることを意味します。関数への各呼び出しは自己記述的であり、メッセージで参照できるクライアントとの以前の会話はありません。そのため、クライアントは「次のページをくれ」と言うことができませんでした。前のページと必要なページの種類を保存するセッションがないため、クライアントは「私の名前はyuval、get特定のフォーラムの特定の投稿のページ2をご覧ください」。つまり、通信でもう少しデータを転送する必要がありますが、「スタックオーバーフローで質問ID 2190836のページ2を取得」とは対照的に、「次のページを取得」機能から報告されたバグを見つけることの違いを考えてください。
もちろん、もっとたくさんありますが、私の意見では、ティースプーンの主要な概念です。
REST はHTTPに特定の機能を追加しませんが、HTTPとともに開発されたアーキテクチャスタイルであり、最も一般的にはアプリケーション層プロトコルにHTTPを使用します。
HTTPはアプリケーションプロトコルです。 RESTはルールのセットであり、これに従うと、特定の望ましい制約のセットを持つ分散アプリケーションを構築できます。
RESTfulアプリケーションとあらゆるHTTPアプリケーションを区別するRESTの最も重要な制約を探している場合、「自己記述」制約とハイパーメディア制約（アプリケーションのエンジンとしてのハイパーメディア）と言います。州（HATEOAS））が最も重要です。
自己記述制約では、RESTfulリクエストがユーザーの意図で完全に自己記述的である必要があります。これにより、仲介者（プロキシおよびキャッシュ）が安全にメッセージを処理できます。
HATEOAS制約は、アプリケーションをリンクのWebに変換することであり、クライアントの現在の状態はそのWeb内の場所に基づいています。これは扱いにくい概念であり、説明するのに今よりも時間がかかります。
そうでもない...
http://en.wikipedia.org/wiki/Representational_State_Transfer
RESTは最初HTTPのコンテキストで説明されましたが、そのプロトコルに限定されません。 RESTfulアーキテクチャは、意味のある表現状態の転送に基づいて、アプリケーションに豊富で統一された語彙を既に提供している場合、他のアプリケーション層プロトコルに基づくことができます。 RESTfulアプリケーションは、既存の明確に定義されたインターフェースと、選択したネットワークプロトコルによって提供されるその他の組み込み機能の使用を最大化し、その上に追加される新しいアプリケーション固有の機能を最小限にします。
http://www.looselycoupled.com/glossary/SOAP
（Simple Object Access Protocol）Webサービスメッセージの標準。 XMLに基づいて、SOAPは、エンベロープ形式とその内容を記述するためのさまざまなルールを定義します。 Webサービスの3つの基本標準の1つとして（WSDLとUDDIを使用して）見られますが、Webサービスを交換するための優先プロトコルですが、決して唯一のプロトコルではありません。 RESTの支持者は、それが不必要な複雑さを追加すると言っています。
私が理解しているように、RESTは使用可能なHTTPコマンドの使用を意図されたとおりに強制します。
たとえば、次のことができます。
GET
http://example.com?method=delete&item=xxx
しかし、残りの場合は、「DELETE」リクエストメソッドを使用し、「method」クエリパラメータの必要性を取り除きます。
DELETE
http://example.com?item=xxx
RESTは、大きなシステム（Webなど）の設計にアプローチする特定の方法です。
それは「ルール」（または「制約」）のセットです。
HTTPは、これらの規則に従うことを試みるプロトコルです。
HTTPは、ネットワークを介してメッセージを転送する通信プロトコルです。 SOAPは、HTTPを使用してこれらのメッセージを転送できるXMLベースのメッセージを交換するためのプロトコルです。 Restは、HTTPを使用してこれらのメッセージを転送できる（XMLまたはJSON）メッセージを交換するためのプロトコルです。
RESTは必ずしもHTTPと結び付けられているわけではありません。 RESTful Webサービスは、RESTfulアーキテクチャに従う単なるWebサービスです。
What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface
REST = Representational State Transfer
RESTは一連のルールであり、このルールに従うと、特定の望ましい制約のセットを持つ分散アプリケーションを構築できます。
RESTは、HTTPを使用してこれらのメッセージを転送できる（XML、JSONなど）メッセージを交換するためのプロトコルです。
機能：
これはステートレスであるため、理想的にはクライアントとサーバー間で接続を維持する必要はありません。コンテキストをサーバーに渡すのはクライアントの責任であり、サーバーはこのコンテキストを保存して、クライアントのさらなるリクエストを処理できます。たとえば、サーバーによって維持されるセッションは、クライアントによって渡されるセッション識別子によって識別されます。
無国籍の利点：
- Webサービスは、各メソッド呼び出しを個別に処理できます。
- Webサービスは、クライアントの以前の対話を維持する必要はありません。
- これにより、アプリケーション設計が簡素化されます。
- HTTPはTCPとは異なり、それ自体がステートレスプロトコルであるため、RESTful WebサービスはHTTPプロトコルとシームレスに動作します。
ステートレス性の欠点：
- クライアントの状態を保持するには、すべての要求に見出しの形で1つの追加レイヤーを追加する必要があります。
- セキュリティのために、すべてのリクエストにヘッダー情報を追加する必要があります。
RESTがサポートするHTTPメソッド：
GET：/ string/someotherstringべき等であり、呼び出しが行われるたびに同じ結果を返すことが理想的です。
PUT：GETと同じです。べき等であり、リソースの更新に使用されます。
POST：リソースの作成に使用されるURLと本文を含む必要があります。複数の呼び出しは理想的には異なる結果を返し、複数の製品を作成する必要があります。
DELETE：サーバー上のリソースを削除するために使用されます。
頭：
HEADメソッドは、サーバーが応答でメッセージ本文を返してはならないことを除いて、GETと同じです。 HEADリクエストへの応答でHTTPヘッダーに含まれるメタ情報は、GETリクエストへの応答で送信された情報と同一である必要があります。
オプション：
このメソッドにより、クライアントは、リソースアクションを示唆したり、リソースの取得を開始したりすることなく、リソースに関連付けられたオプションや要件、またはサーバーの機能を決定できます。
HTTPレスポンス
ここにいくつかの重要なものがあります：200-OK 3XX-クライアントとURLリダイレクトから必要な追加情報400-不正なリクエスト
401-アクセスが許可されていません
403禁止します
リクエストは有効でしたが、サーバーはアクションを拒否しています。ユーザーがリソースに必要な権限を持っていないか、何らかのアカウントが必要な場合があります。
404お探しのページが見つかりませんでした
リクエストされたリソースは見つかりませんでしたが、将来利用可能になる可能性があります。クライアントによる後続のリクエストは許可されます。
405-Method Not Allowed要求されたリソースでは要求メソッドはサポートされていません。たとえば、POSTを介してデータを提示する必要があるフォームでのGET要求、または読み取り専用リソースでのPUT要求。
404-リクエストが見つかりません
500-内部サーバー障害
502-不正なゲートウェイエラー
したがって、RESTアーキテクチャとHTTP 1.1プロトコルは互いに独立していますが、HTTP 1.1プロトコルはRESTの原則と制約に従う理想的なプロトコルとして構築されました。 HTTPとRESTの関係を調べる1つの方法は、RESTが設計であり、HTTP 1.1がその設計の実装であるということです。
HTTP is a contract, a communication protocol and REST is a concept, an architectural style。HTTP、FTP、またはその他の通信プロトコルを使用できますが、HTTPで広く使用されています。
REST implies a series of constraints about how Server and Client should interact。 HTTP is a communication protocol with a given mechanism for server-client data transfer、RESTの前にREST was inspired by WWW (world wide web) which largely used HTTPが定義されたという理由だけでREST APIで最も一般的に使用されるため、HTTPでREST APIスタイルを実装するのが簡単です。
There are three major constraints in REST (but there are more):
1.サーバーとクライアント間の相互作用は、ハイパーテキストのみで記述する必要があります。
2.サーバーとクライアントは疎結合であり、互いについて何も仮定しないでください。クライアントはリソースエントリポイントのみを知っている必要があります。相互作用データは、応答でサーバーによって提供される必要があります。
3.サーバーは、リクエストコンテキストに関する情報を保存しないでください。リクエストは独立してi等である必要があります（同じリクエストが無限に繰り返される場合、まったく同じ結果が取得されることを意味します）
HTTPは、これを達成するのに役立つ通信プロトコル（ツール）にすぎません。
詳細については、次のリンクを確認してください。
https://martinfowler.com/articles/richardsonMaturityModel.htmlhttp://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
REST APIはハイパーテキスト駆動である必要があります
Roy Fieldingのブログ から、HTTP APIまたはREST APIを構築しているかどうかを確認する一連の方法を次に示します。
APIデザイナーは、作成をREST APIに呼び出す前に、次のルールに注意してください。
- REST APIは、単一の通信プロトコルに依存するべきではありませんが、特定のプロトコルへのマッピングが成功するかどうかは、メタデータの可用性、メソッドの選択などに依存する場合があります。識別用のURIは、その識別のためにURIスキームの使用を許可する必要があります。 [ここでの失敗は、識別が相互作用から分離されていないことを意味します。]
- REST APIには、HTTPのPATCHメソッドやリンクヘッダーフィールドなど、標準プロトコルの指定不足のビットの詳細を入力または修正する以外に、通信プロトコルへの変更を含めないでください。壊れた実装（HTMLがHTTPのメソッドセットを定義していると信じるほど愚かなブラウザなど）の回避策は、回避策が最終的に廃止されることを期待して、個別に、または少なくとも付録で定義する必要があります。 [ここでの失敗は、リソースインターフェイスがオブジェクト固有であり、汎用ではないことを意味します。]
- REST APIは、リソースの表現とアプリケーションの状態の駆動に使用されるメディアタイプの定義、または拡張リレーション名および/またはハイパーテキスト対応マークアップの定義に、ほぼすべての記述的労力を費やします既存の標準メディアタイプ。関心のあるURIでどのメソッドを使用するかを記述する努力は、メディアタイプの処理ルールの範囲内で完全に定義する必要があります（ほとんどの場合、既存のメディアタイプで既に定義されています）。 [ここでの失敗は、帯域外情報がハイパーテキストの代わりに相互作用を促進していることを意味します。]
- REST APIは、固定リソース名または階層（クライアントとサーバーの明らかな結合）を定義してはなりません。サーバーには、独自の名前空間を制御する自由が必要です。代わりに、メディアタイプとリンク関係内でそれらの命令を定義することにより、HTMLフォームやURIテンプレートで行われるような適切なURIの構築方法についてサーバーがクライアントに指示できるようにします。 [ここでの失敗は、クライアントがRPCの機能的なカップリングと同等のデータ指向のドメイン固有の標準など、帯域外情報のためにリソース構造を想定していることを意味します]。
- REST APIには、クライアントにとって重要な「型付きの」リソースを含めることはできません。仕様の作成者は、インターフェイスの背後にあるサーバーの実装を記述するためにリソースタイプを使用できますが、これらのタイプは無関係であり、クライアントには見えない必要があります。クライアントにとって重要なタイプは、現在の表現のメディアタイプと標準化された関係名のみです。 [同じ]
- REST APIは、最初のURI（ブックマーク）を超えて事前知識なしで入力する必要があります。また、対象の視聴者に適した標準メディアタイプのセット（つまり、 API）。その時点から、すべてのアプリケーションの状態遷移は、受信した表現に存在する、またはユーザーがそれらの表現を操作することによって暗示されるサーバー提供の選択肢のクライアント選択によって駆動される必要があります。遷移は、メディアタイプとリソース通信メカニズムに関するクライアントの知識によって決定（または制限）することができます。どちらもオンザフライ（コードオンデマンドなど）で改善できます。 [ここでの失敗は、帯域外情報がハイパーテキストの代わりに相互作用を促進していることを意味します。]