RESTとは何か、SOAPとは何かをわかりやすい英語で説明できますか? また、Web サービスはどのように機能するのでしょうか?
Vicky
質問する
282343 次
14 に答える
1592
SOAPとRESTの簡単な説明
SOAP - 「シンプル オブジェクト アクセス プロトコル」
SOAP は、インターネットを介してメッセージまたは少量の情報を転送する方法です。SOAP メッセージは XML でフォーマットされ、通常は HTTP (ハイパーテキスト転送プロトコル) を使用して送信されます。
Rest - 代表的な状態の転送
Rest は、クライアントとサーバー間でデータを送受信する簡単な方法であり、多くの標準が定義されていません。JSON、XML、またはプレーンテキストとしてデータを送受信できます。SOAP に比べて軽量です。
于 2012-01-24T07:02:02.637 に答える
327
どちらの方法も、大規模なプレーヤーの多くで使用されています。それは好みの問題です。私の好みは REST です。なぜなら、REST の方が使いやすく、理解しやすいからです。
シンプル オブジェクト アクセス プロトコル (SOAP):
- SOAP は、HTTP または場合によっては TCP/IP の上に XML プロトコルを構築します。
- SOAP は、関数とデータの型を記述します。
- SOAP は XML-RPC の後継であり、非常に似ていますが、標準的な通信方法を記述しています。
- いくつかのプログラミング言語は SOAP をネイティブでサポートしています。通常、SOAP に Web サービス URL をフィードすると、特定のコードを必要とせずにその Web サービス関数を呼び出すことができます。
- 送信されるバイナリ データは、最初に base64 エンコードなどの形式にエンコードする必要があります。
- それに関連するいくつかのプロトコルとテクノロジがあります: WSDL、XSD、SOAP、WS-Addressing
Representational State Transfer (REST):
- REST は HTTP 経由である必要はありませんが、以下のポイントのほとんどには HTTP バイアスがあります。
- REST は非常に軽量です。SOAP が作成したこの複雑さはすべて必要ありません。
- 通常、すべてを記述する大きな XML 形式ではなく、通常の HTTP メソッドを使用します。たとえば、HTTP GET を使用してリソースを取得するには、HTTP PUT を使用してサーバーにリソースを配置します。サーバー上のリソースを削除するには、HTTP DELETE を使用します。
- REST は、HTTP GET、POST、および PUT メソッドを使用してサーバー上のリソースを更新するという点で非常に単純です。
- 通常、REST はリソース指向アーキテクチャ(ROA) で使用するのが最適です。この考え方では、すべてがリソースであり、これらのリソースを操作します。
- プログラミング言語に HTTP ライブラリがあれば (ほとんどの場合)、REST HTTP プロトコルを非常に簡単に使用できます。
- バイナリ データまたはバイナリ リソースは、要求に応じて簡単に配信できます。
Google では、REST と SOAP の対比について果てしない議論があります。
私のお気に入りはこれです。2013 年 11 月 27 日の更新: Paul Prescod のサイトはオフラインになったようで、この記事は利用できなくなりました。
于 2008-10-16T19:33:52.027 に答える
265
休み
REST の主な考え方は非常に単純であることは理解しています。私たちは何年も Web ブラウザーを使用しており、Web サイトがいかに簡単で、柔軟で、パフォーマンスが高いかを見てきました。HTML サイトは、ハイパーリンクとフォームをユーザーの主要な対話手段として使用します。彼らの主な目標は、私たち、クライアントが、現在の状態で使用できるリンクのみを知ることができるようにすることです. そして、REST は単に「同じ原則を使用して、アプリケーションを通じて人間のクライアントではなくコンピューターを駆動しないのはなぜですか?」と言っています。これを WWW インフラストラクチャの機能と組み合わせると、優れた分散アプリケーションを構築するためのキラー ツールが得られます。
別の考えられる説明は、数学的に考える人々のためのものです。各アプリケーションは基本的に、状態遷移であるビジネス ロジック アクションを備えたステート マシンです。REST の考え方は、各遷移をリソースへの何らかの要求にマップし、現在の状態で利用可能な遷移を表すリンクをクライアントに提供することです。したがって、表現とリンクを介してステート マシンをモデル化します。これが REpresentational State Transfer と呼ばれる理由です。
すべての回答がメッセージ形式または HTTP 動詞の使用法に焦点を当てているように見えるのは非常に驚くべきことです。実際、メッセージ形式はまったく問題ではありません。REST は、サービス開発者がそれを文書化している限り、任意の形式を使用できます。HTTP 動詞は、サービスを CRUD サービスにするだけで、まだ RESTful ではありません。サービスを実際に REST サービスに変えるのは、サーバーの応答にデータと共に埋め込まれたハイパーリンク (別名ハイパーメディア コントロール) であり、その量は、クライアントがそれらのリンクから次のアクションを選択するのに十分でなければなりません。
残念ながら、 Roy Fielding の論文を除いて、REST に関する正しい情報を Web 上で見つけるのはかなり困難です。(REST を派生させたのは彼です)。SOAP から REST に進化する方法について、段階を追った包括的なチュートリアルが提供されている「REST in Practice」という本をお勧めします。
石鹸
これは、RPC (リモート プロシージャ コール) アーキテクチャ スタイルの可能な形式の 1 つです。本質的には、ローカル メソッドを呼び出しているかのように、クライアントがサービス境界 (ネットワーク、プロセスなど) を介してサーバーのメソッドを呼び出せるようにする単なるテクノロジです。もちろん、実際には速度や信頼性などでローカル メソッドを呼び出すのとは異なりますが、考え方は単純です。
比較した
トランスポート プロトコル、メッセージ形式、xsd、wsdl などの詳細は、任意の形式の RPC を REST と比較する場合には関係ありません。主な違いは、RPC サービスだけが知っているセマンティクスを使用して RPC API で独自のアプリケーション プロトコルを設計することにより、RPC サービスが自転車を再発明することです。したがって、すべてのクライアントはサービスを使用する前にこのプロトコルを理解する必要があり、すべての要求の独自のセマンティクスのために、キャッシュのような一般的なインフラストラクチャを構築することはできません。さらに、RPC API は、現在の状態で許可されているアクションを示唆していません。これは、追加のドキュメントから導き出す必要があります。一方、REST は、統一されたインターフェイスを使用して、さまざまなクライアントが API セマンティクスをある程度理解できるようにし、ハイパーメディア コントロール (リンク) を使用して、各状態で利用可能なオプションを強調表示することを意味します。したがって、
ある意味で、SOAP は (他のすべての RPC と同様に) サービス境界をトンネリングして、接続メディアをメッセージのみを送信できるブラック ボックスとして扱う試みです。REST は、Web が巨大な分散情報システムであることを認め、世界をありのままに受け入れ、それと戦うのではなくそれを習得することを学ぶための決定です。
サーバーとクライアントの両方を制御し、相互作用がそれほど複雑でない場合、SOAP は内部ネットワーク API に適しているようです。開発者がそれを使用する方が自然です。ただし、多くの独立関係者によって使用され、複雑で大規模なパブリック API の場合、REST の方が適しているはずです。しかし、この最後の比較は非常にあいまいです。
アップデート
私の経験では、予期せず REST 開発が SOAP よりも難しいことがわかりました。少なくとも .NET の場合。ASP.NET Web API のような優れたフレームワークはありますが、クライアント側のプロキシを自動的に生成するツールはありません。「Web サービス参照の追加」や「WCF サービス参照の追加」のようなものはありません。すべてのシリアライゼーションとサービス クエリ コードを手動で記述する必要があります。そして、それはたくさんの定型コードです。REST 開発には、開発プラットフォームごとに WSDL とツールの実装に似たものが必要だと思います。実際には、 WADLまたはWSDL 2.0という適切な根拠があるようですが、どちらの標準も十分にサポートされているようには見えません。
更新 (2016 年 1 月)
現在、REST API 定義用のさまざまなツールがあることがわかりました。私の個人的な好みは現在RAMLです。
Web サービスのしくみ
特定の Web サービスで使用されるアーキテクチャとテクノロジに依存するため、これは広すぎる質問です。ただし、一般に、Web サービスは、クライアントからの要求を受け入れて応答を返すことができる Web 内のアプリケーションです。これは Web に公開されているため、Webサービスであり、通常は 24 時間年中無休で利用できます。これがサービスである理由です。もちろん、それはそのクライアントの問題を解決します (そうでなければ、なぜ誰かが Web サービスを使用するのでしょうか)。
于 2012-09-19T18:41:07.547 に答える
41
これは、これまでで最も簡単な説明です。
この記事では、夫が妻に REST について純粋に素人の言葉で説明する、夫から妻への物語を取り上げます。必読！
how-i-explained-rest-to-my-wife (元のリンク)
how-i-explained-rest-to-my-wife (2013-07-19 作業リンク)
于 2012-07-13T07:33:22.700 に答える
38
SOAP - Simple Object Access Protocolはプロトコルです。
REST - REpresentational State Transferはアーキテクチャ スタイルです。
SOAPメッセージの転送に使用される XML プロトコルで、通常は HTTP を介して
REST間違いなく、相互に排他的でSOAPはありません。RESTful アーキテクチャは、またはその他の通信プロトコルを使用する場合があります。Web 用に最適化されているため、最適な選択です。Roy Fielding の論文で議論されている唯一のプロトコルでもあります。 HTTPSOAPRESTHTTPHTTP
RESTREST と SOAP は明らかに大きく異なりますが、この質問は、とHTTPがしばしば併用されるという事実を浮き彫りにします。これは主に、HTTP の単純さと、RESTful 原則への非常に自然なマッピングによるものです。
REST の基本原則
クライアントサーバー通信
クライアント/サーバー アーキテクチャでは、関心事項が非常に明確に分離されています。RESTful スタイルで構築されたすべてのアプリケーションは、原則としてクライアント サーバー型でなければなりません。
ステートレス
サーバーへの各クライアント要求では、その状態が完全に表現されている必要があります。サーバーは、サーバー コンテキストやサーバー セッション状態を使用せずに、クライアントの要求を完全に理解できる必要があります。したがって、すべての状態をクライアントで保持する必要があります。ステートレス表現については後で詳しく説明します。
キャッシュ可能
キャッシュ制約を使用して、応答データをキャッシュ可能またはキャッシュ不可としてマークできるようにすることができます。キャッシュ可能としてマークされたデータは、同じ後続のリクエストへのレスポンスとして再利用できます。
統一インターフェース
すべてのコンポーネントは、単一の統一されたインターフェイスを介して対話する必要があります。すべてのコンポーネントの対話はこのインターフェースを介して行われるため、さまざまなサービスとの対話は非常に簡単です。インターフェースはそのまま！これは、実装の変更を個別に行うことができることも意味します。統一されたインターフェースは常に変更されないため、このような変更は基本的なコンポーネントの相互作用には影響しません。欠点の 1 つは、インターフェイスに固執することです。インターフェイスを変更することで特定のサービスに最適化を提供できたとしても、REST ではこれが禁止されているため、うまくいきません。ただし、明るい面としては、REST は Web 用に最適化されているため、REST over HTTP は非常に人気があります。
上記の概念は、REST の定義特性を表し、REST アーキテクチャを Web サービスなどの他のアーキテクチャと区別します。REST サービスは Web サービスですが、Web サービスは必ずしも REST サービスであるとは限りません。
RESTと上記の箇条書きの詳細については、REST 設計プリンシパルに関するこのブログ投稿を参照してください。
于 2014-03-14T20:28:05.577 に答える
12
ブライアン・R・ボンディの答えが好きです。ウィキペディアがRESTの明確な説明を提供していることを付け加えたかっただけです。この記事では、SOAP と区別しています。
REST は状態情報の交換であり、可能な限り単純に行われます。
SOAP は、XML を使用するメッセージ プロトコルです。
多くの人が SOAP から REST に移行した主な理由の 1 つは、SOAP ベースの Web サービスに関連する WS-* (WS スプラットと呼ばれる) 標準が非常に複雑であることです。仕様のリストについては、wikipediaを参照してください。これらの各仕様は非常に複雑です。
編集: 何らかの理由でリンクが正しく表示されません。REST = http://en.wikipedia.org/wiki/REST
于 2008-10-16T19:47:34.340 に答える
6
では、2 番目の質問から始めましょう。Web サービスとは何ですか? 、明らかな理由から。
WebServices は基本的に、特定の機能またはデータを公開するロジックの断片 (あいまいにメソッドと呼ぶ場合があります) です。実装するクライアント (技術的に言えば、消費とは言葉です) は、メソッドが受け入れるパラメーターと、それが返すデータのタイプ (もしそうなら) を知る必要があるだけです。
次のリンクは、RESTとSOAPについて非常に明快に説明しています。
また、いつ何 (REST または SOAP) を選択するかを知りたい場合は、それを実行するよりも多くの理由があります!
于 2012-10-11T07:39:07.400 に答える
5
SOAP と REST はどちらも、異なるシステムが互いに通信する方法を指します。
REST は、ブラウザーが Web サーバーと行う通信に似た手法を使用してこれを行います。GET を使用して Web ページを要求したり、フォーム フィールドで POST を使用したりするなどです。
SOAP は似たようなものを提供しますが、XML のブロックをやり取りすることですべてを行います。SOAP のもう 1 つの重要なコンポーネントは WSDL です。これは、サポートされている機能とデータ要素を記述した XML ドキュメントです。WSDL を使用すると、サポートされている機能をプログラムで「検出」したり、プログラミング コード スタブを生成したりできます。
于 2009-07-04T06:09:09.393 に答える
3
SOAP の問題は、HTTP スタックの背後にある理想と矛盾していることです。ミドルウェアは、リクエストまたはレスポンスの内容を理解せずに HTTP リクエストを操作できる必要がありますが、たとえば、通常の HTTP キャッシュ サーバーは、SOAP コンテンツのどの部分がキャッシュに関係するかを知らずに SOAP リクエストを操作することはできません。SOAP は、HTTP をプロキシのような独自の通信プロトコルのラッパーとして使用するだけです。
于 2009-07-20T17:54:23.117 に答える
2
これは私が説明できるほど簡単だと思います。誰でも私を修正したり、これに追加したりできます。
SOAP は、切断されたシステム (インターネット全体など) が情報/データを交換するために使用するメッセージ形式です。これは、XML メッセージのやり取りを行います。
Web サービスは、SOAP メッセージを送受信します。どの言語で書かれているかによって、動作が異なります。
于 2008-10-16T19:30:54.217 に答える
2
REST は、ネットワーク化されたアプリケーションを設計するためのアーキテクチャ スタイルです。CORBA、RPC、SOAP などの複雑なメカニズムを使用してマシン間を接続するのではなく、単純な HTTP を使用してマシン間の呼び出しを行うという考え方です。
于 2013-06-11T10:13:38.090 に答える
1
SOAP – 「シンプル オブジェクト アクセス プロトコル」
SOAPは、インターネット上でメッセージまたは少量の情報を転送するためのものです。SOAPメッセージはXMLでフォーマットされ、通常はHTTPを制御して送信されます。
REST – "REpresentational State Transfer"
RESTは、ファンとサーバー間での不測の事態と情報受信の初歩的な手順であり、多くの標準が明確に定義されているわけではありません。JSON、XML、またはプレーンテキストとして情報を送受信できます。SOAPに比べて軽量です。
于 2015-02-04T16:34:00.887 に答える
-4
SOAP ベースの Web サービス 要するに、SOAP ベースのサービス モデルは、世界を、相互に制御することはできませんが、公開されたコントラクトを尊重することによって連携しなければならない同等のピアのエコシステムと見なします。これは乱雑な現実世界の有効なモデルであり、メタデータ ベースのコントラクトが SOAP サービス インターフェイスを形成します。
SOAP を XML ベースのリモート プロシージャ コールと関連付けることはできますが、SOAP ベースの Web サービス テクノロジは柔軟で強力なメッセージング モデルとして登場しました。
SOAP は、すべてのシステムが独立しており、他のシステムや内部機能の内部構造を認識しているシステムはないと想定しています。そのようなシステムができることのほとんどは、互いにメッセージを送信し、それらが実行されることを期待することです. システムは、遵守することを約束するコントラクトを発行し、他のシステムはこれらのコントラクトに依存してメッセージを交換します。
システム間のコントラクトはまとめてメタデータと呼ばれ、サービスの説明、サポートされるメッセージ交換パターン、およびサービスの品質を管理するポリシー (サービスの暗号化、確実な配信などが必要になる場合があります) で構成されます。システムが送受信するデータ (メッセージ文書) の仕様。ドキュメントは、XML スキーマ定義のような XML 記述言語を使用して記述されます。すべてのシステムが公開されたコントラクトを尊重している限り、相互運用が可能であり、システムの内部の変更が他のシステムに影響を与えることはありません。すべてのシステムは、独自の内部実装をコントラクトとの間で変換する責任があります
REST - 代表的な状態転送。物理プロトコルは HTTP です。基本的に、REST は、URL によって一意に識別できる Web 上のすべての個別のリソースです。これらのリソースで実行できるすべての操作は、限定された一連の動詞 (「CRUD」動詞) で記述できます。これらの動詞は、HTTP 動詞にマップされます。
REST は SOAP よりもはるかに「重く」ありません。
于 2013-10-19T06:46:10.220 に答える