HTTPとRESTの違いは何ですか？

RESTとSOAPの違いについてたくさん読んだ後、RESTはHTTPの単なる別の言葉であるという印象を受けました。RESTがHTTPに追加する機能について誰かが説明できますか？

注：RESTとSOAPの比較を探しているのではありません。

更新：ご回答ありがとうございます。RESTは、HTTPの使用方法に関する一連のルールにすぎないことが明らかになりました。したがって、私はこれらの規則の利点が何であるかについてフォローアップを投稿しました。

注：RESTの意味を理解しました。エミールイワノフのあることを意味していますHTTPの方法を使用して発言、REST手段。しかし、これが独自の用語に値するかどうかはわかりませんし、確かに誇大宣伝はありません。

いいえ、RESTは道であるHTTPをしなければならない使用します。

今日では、HTTPプロトコルのメソッドのほんの一部、つまりGETおよびのみを使用していますPOST。それを行うRESTの方法は、プロトコルのすべてのメソッドを使用することです。

たとえば、RESTはDELETE、URIの背後にあるドキュメント（ファイル、状態など）を消去するためのの使用を指示しますが、HTTPでは、GETまたはのPOSTようなクエリを誤用します...product/?delete_id=22。

HTTPは通信に使用されるプロトコルであり、通常、インターネットリソースやWebブラウザクライアントを使用するアプリケーションとの通信に使用されます。

RESTは、アプリケーションの設計中に使用する主な概念がリソースであることを意味します。実行するアクションごとに、通常CRUD操作のみを実行するリソースを定義する必要があります。これは簡単なタスクです。そのため、4つのCRUD操作に対してHTTPプロトコルで使用される4つの動詞を使用するのが非常に便利です（Get for Read、POSTはCREATE、PUTはUPDATE、DELETEはDELETEです）。これは、RPC（リモートプロシージャコール）の以前の概念とは異なります。RPC（リモートプロシージャコール）では、ユーザーの呼び出しの結果として実行する一連のアクションがあります。たとえば、投稿のようにFacebookを記述する方法を考える場合、RPCを使用してAddLikeToPostおよびRemoveLikeFromPostというサービスを作成し、FB投稿に関連する他のすべてのサービスと一緒に管理することができるため、特別なものを作成する必要はありません。 Likeのオブジェクト。RESTを使用すると、削除および作成機能で個別に管理されるLikeオブジェクトが作成されます。また、db内の別のエンティティを記述することも意味します。それは小さな違いのように見えるかもしれませんが、そのように動作すると、通常ははるかに単純なコードとはるかに単純なアプリケーションが生成されます。その設計では、通常多くのロジックを明示的に追加する必要があるRPCとは異なり、アプリのロジックのほとんどはオブジェクトの構造（モデル）から明らかです。

RESTfulアプリケーションの設計は、複雑なことを簡単な方法で説明する必要があるため、通常ははるかに困難です。CRUD関数のみを使用してすべての機能を説明するのは難しいですが、それを実行すると、人生はずっと単純になり、はるかに短いメソッドを書くことがわかります。

存在するもう1つの制約RESTアーキテクチャは、クライアント（ステートレス）との通信時にセッションコンテキストを使用しないことです。つまり、すべての情報は、誰がクライアントであり、何が欲しいのかをWebメッセージとともに渡す必要があります。関数の各呼び出しは自己記述的であり、メッセージで参照できるクライアントとの以前の会話はありません。そのため、前のページが何で、どのような種類のページが必要かを保存するセッションがないため、クライアントは「次のページを教えて」と言うことができませんでした。クライアントは「私の名前はyuval、get特定のフォーラムの特定の投稿の2ページ目」。つまり、通信で転送する必要のあるデータが少し増えることになりますが、「次のページを取得」機能から報告されたバグを見つけるのではなく、「

もちろん、それだけではありませんが、小さじ1杯の主なコンセプトは私の意見です。

HTTPはアプリケーションプロトコルです。RESTは一連のルールであり、これに従うと、特定の一連の望ましい制約を持つ分散アプリケーションを構築できます。

RESTfulアプリケーションを単なるHTTPアプリケーションと区別するRESTの最も重要な制約を探している場合、「自己記述」制約とハイパーメディア制約（アプリケーション状態のエンジン（HATEOAS）としてのハイパーメディア）は次のようになります。最も重要な。

自己記述型制約では、RESTfulリクエストがユーザーの意図を完全に自己記述的にする必要があります。これにより、仲介者（プロキシとキャッシュ）がメッセージを安全に処理できます。

HATEOAS制約は、クライアントの現在の状態がそのWeb内の場所に基づいているリンクのWebにアプリケーションを変換することです。これはトリッキーなコンセプトで、今説明しているよりも説明に時間がかかります。

私が理解しているように、RESTは使用可能なHTTPコマンドを使用することを意図していたため、それらの使用を強制します。

たとえば、次のことができます。

GET
http://example.com?method=delete&item=xxx

しかし、残りの部分では、「DELETE」リクエストメソッドを使用して、「メソッド」クエリパラメータの必要性を排除

DELETE
http://example.com?item=xxx

なかなか...

http://en.wikipedia.org/wiki/Representational_State_Transfer

RESTは当初HTTPのコンテキストで説明されましたが、そのプロトコルに限定されません。RESTfulアーキテクチャは、意味のある表現状態の転送に基づいて、アプリケーションに豊富で統一された語彙をすでに提供している場合、他のアプリケーション層プロトコルに基づくことができます。RESTfulアプリケーションは、既存の明確に定義されたインターフェイスと、選択したネットワークプロトコルによって提供されるその他の組み込み機能の使用を最大化し、その上に新しいアプリケーション固有の機能の追加を最小限に抑えます。

http://www.looselycoupled.com/glossary/SOAP

（Simple Object Access Protocol）Webサービスメッセージの標準。SOAPはXMLに基づいて、エンベロープ形式とその内容を記述するためのさまざまなルールを定義します。（WSDLおよびUDDIとともに）Webサービスの3つの基本標準の1つと見なされており、Webサービスを交換するための推奨プロトコルですが、それだけではありません。RESTの支持者は、それが不必要な複雑さを追加すると言っています。

RESTは、（Webなどの）大きなシステムの設計に取り組むための特定の方法です。

これは、「ルール」（または「制約」）のセットです。

HTTPは、これらのルールに従おうとするプロトコルです。

REST =表現状態の転送

RESTは一連のルールであり、これに従うと、特定の一連の望ましい制約を持つ分散アプリケーションを構築できます。

RESTは、HTTPを使用してメッセージを転送できる任意の（XML、JSONなど）メッセージを交換するためのプロトコルです。

特徴：

これはステートレスであり、理想的にはクライアントとサーバー間の接続を維持する必要はありません。コンテキストをサーバーに渡すのはクライアントの責任であり、サーバーはこのコンテキストを保存してクライアントのその後のリクエストを処理できます。たとえば、サーバーによって維持されるセッションは、クライアントによって渡されるセッション識別子によって識別されます。

無国籍の利点：

1. Webサービスは、各メソッド呼び出しを個別に処理できます。
2. Webサービスは、クライアントの以前の対話を維持する必要はありません。
3. これにより、アプリケーションの設計が簡素化されます。
4. HTTP自体は、TCPとは異なりステートレスプロトコルであるため、RESTful WebサービスはHTTPプロトコルとシームレスに連携します。

無国籍の欠点：

1. クライアントの状態を保持するには、すべてのリクエストに見出しの形で1つの追加レイヤーを追加する必要があります。
2. セキュリティのため、すべてのリクエストにヘッダー情報を追加する必要があります。

RESTがサポートするHTTPメソッド：

GET：/ string / someotherstringべき等であり、呼び出しが行われるたびに同じ結果を返すのが理想的です

PUT：GETと同じです。べき等であり、リソースの更新に使用されます。

POST：リソースの作成に使用されるURLと本文を含める必要があります。複数の呼び出しが理想的には異なる結果を返し、複数の製品を作成する必要があります。

DELETE：サーバー上のリソースを削除するために使用されます。

頭：

HEADメソッドは、サーバーが応答でメッセージ本文を返してはならないことを除いて、GETと同じです。HEADリクエストへの応答でHTTPヘッダーに含まれるメタ情報は、GETリクエストへの応答で送信される情報と同一である必要があります（SHOULD）。

オプション：

このメソッドを使用すると、クライアントは、リソースアクションを示唆したり、リソースの取得を開始したりすることなく、リソースに関連するオプションや要件、またはサーバーの機能を決定できます。

HTTP応答

すべての回答については、こちらをご覧ください。

ここではいくつかの重要なものは次のとおりです：200 - OK 3XX -バート要求-クライアントとリダイレクト400から必要に応じて追加情報
401 -アクセスへの不正な
403 -禁断の
要求が有効であったが、サーバーがアクションを拒否しています。ユーザーには、リソースに必要な権限がないか、何らかのアカウントが必要な場合があります。

404-見つかりません
要求されたリソースは見つかりませんでしたが、将来利用できる可能性があります。クライアントによるその後の要求は許可されます。

405-メソッドは許可されていません要求されたリソースでは、要求メソッドはサポートされていません。たとえば、POSTを介してデータを提示する必要があるフォームに対するGETリクエストや、読み取り専用リソースに対するPUTリクエストなどです。

404-リクエストが見つかりません
500-内部サーバーエラー
502-不正なゲートウェイエラー

HTTPは、ネットワークを介してメッセージを転送する通信プロトコルです。SOAPは、HTTPを使用してメッセージを転送できるXMLベースのメッセージを交換するためのプロトコルです。Restは、HTTPを使用してメッセージを転送できる（XMLまたはJSON）メッセージを交換するためのプロトコルです。

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 APIで最も一般的に使用されREST was inspired by WWW (world wide web) which largely used HTTPているのは、RESTが定義される前なので、REST APIスタイルをHTTPで実装する方が簡単です。

There are three major constraints in REST (but there are more):

1. サーバーとクライアント間の相互作用は、ハイパーテキストのみで説明する必要があります。

2.サーバーとクライアントは疎結合であり、互いについて仮定しないでください。クライアントはリソースのエントリポイントのみを知っている必要があります。インタラクションデータは、サーバーがレスポンスで提供する必要があります。

3.サーバーはリクエストコンテキストに関する情報を保存するべきではありません。リクエストは独立してべき等である必要があります（同じリクエストが無限に繰り返された場合、まったく同じ結果が取得されます）

そしてHTTPは、これを実現するのに役立つ通信プロトコル（ツール）にすぎません。

詳細については、次のリンクを確認してください：

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

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

あなたはHTTPとRESTの違いを知りません

したがって、RESTアーキテクチャーとHTTP 1.1プロトコルは互いに独立していますが、HTTP 1.1プロトコルはRESTの原則と制約に従う理想的なプロトコルとして構築されました。HTTPとRESTの関係を調べる1つの方法は、RESTが設計であり、HTTP 1.1がその設計の実装であることです。

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は、固定リソース名または階層（クライアントとサーバーの明らかな結合）を定義してはなりません。サーバーは、独自の名前空間を自由に制御できる必要があります。代わりに、サーバーがクライアントに適切なURIを構築する方法を指示できるようにします。たとえば、メディアタイプとリンク関係内でそれらの指示を定義することにより、HTMLフォームやURIテンプレートで行われます。[ここでの障害は、RPCの機能的結合と同等のデータ指向のドメイン固有の標準など、帯域外情報のためにクライアントがリソース構造を想定していることを意味します]
• REST APIには、クライアントにとって重要な「型付けされた」リソースがあってはなりません。仕様の作成者は、インターフェイスの背後にあるサーバーの実装を説明するためにリソースタイプを使用できますが、それらのタイプは無関係であり、クライアントからは見えません。クライアントにとって重要な唯一のタイプは、現在の表現のメディアタイプと標準化された関係名です。[同上]
• REST APIは、最初のURI（ブックマーク）と、対象のオーディエンスに適した標準化されたメディアタイプのセット（つまり、APIを使用する可能性のあるクライアントによって理解されることが期待される）以外の事前知識なしで入力する必要があります。その時点から、すべてのアプリケーションの状態遷移は、受信した表現に存在する、またはユーザーによるそれらの表現の操作によって暗示される、サーバー提供の選択肢のクライアント選択によって駆動される必要があります。遷移は、クライアントのメディアタイプとリソース通信メカニズムの知識を決定（または制限）できます。どちらもオンザフライで改善できます（たとえば、コードオンデマンド）。[ここでの失敗は、帯域外の情報がハイパーテキストではなく対話を促進していることを意味します。]