Web サービス通信プロトコルとしての SOAP と REST の違いについての記事を読みましたが、SOAP に対する REST の最大の利点は次の点だと思います。
REST はより動的であり、UDDI (Universal Description, Discovery, and Integration) を作成および更新する必要はありません。
REST は XML 形式だけに限定されません。RESTful Web サービスはプレーンテキスト/JSON/XML を送信できます。
しかし、SOAP はより標準化されています (例: セキュリティ)。
それで、これらの点において私の言うことは正しいでしょうか?
ベストアンサー1
残念ながら、RESTについては多くの誤った情報や誤解があります。あなたの質問や@cmd による回答これらは反映されていますが、Stack Overflow 上のこのテーマに関連する質問と回答のほとんどは反映されていません。
SOAP と REST を直接比較することはできません。前者はプロトコル (または少なくともプロトコルになろうとしている) であり、後者はアーキテクチャ スタイルだからです。SOAP 以外の HTTP API はすべて REST と呼ばれる傾向があるため、これが混乱の原因の 1 つであると考えられます。
少し踏み込んで比較してみると、SOAP と REST の主な違いは、クライアントとサーバーの実装間の結合度合いです。SOAP クライアントは、サーバーに密に結合されたカスタム デスクトップ アプリケーションのように動作します。クライアントとサーバーの間には厳格な契約があり、どちらかの側で何かを変更するとすべてが壊れることが予想されます。変更があった場合は常に更新が必要ですが、契約が守られているかどうかを確認するのは簡単です。
REST クライアントは、ブラウザに似ています。これは、プロトコルと標準化されたメソッドの使用方法を知っている汎用クライアントであり、アプリケーションはその中に適合する必要があります。追加のメソッドを作成してプロトコル標準に違反するのではなく、標準メソッドを活用して、メディア タイプでそれらのメソッドを使用してアクションを作成します。正しく実行すれば、結合が少なくなり、変更をより適切に処理できます。クライアントは、エントリ ポイントとメディア タイプ以外の API に関する知識をまったく持たずに REST サービスに入ることになっています。SOAP では、クライアントは使用するすべてのものに関する事前の知識を必要とします。そうしないと、対話を開始できません。さらに、REST クライアントは、サーバー自体によって提供されるオンデマンド コードによって拡張できます。典型的な例は、クライアント側で別のサービスとの対話を駆動するために使用される JavaScript コードです。
REST とは何か、そして SOAP とどう違うのかを理解するには、次の点が重要だと思います。
REST はプロトコルに依存しません。HTTP とは結合されていません。Web サイトで FTP リンクをたどることができるのと同じように、REST アプリケーションは標準化された URI スキームがある任意のプロトコルを使用できます。
RESTはCRUDをHTTPメソッドにマッピングするものではありません。これ詳しい説明については回答してください。
REST は、使用しているパーツと同様に標準化されています。HTTP のセキュリティと認証は標準化されているため、HTTP 経由で REST を実行するときに使用します。
RESTはRESTではないハイパーメディアそしてヘイトアスつまり、クライアントはエントリ ポイント URI のみを認識し、リソースはクライアントがたどるべきリンクを返すことになります。REST API で実行できるすべてのことに対して URI パターンを提供する派手なドキュメント ジェネレーターは、要点を完全に見逃しています。標準に従うべきことをドキュメント化するだけでなく、それを行うと、クライアントを API の進化の特定の瞬間に結び付けることになり、API の変更はすべてドキュメント化して適用する必要があります。そうしないと、API が壊れてしまいます。
REST は Web 自体のアーキテクチャ スタイルです。Stack Overflow にアクセスすると、ユーザー、質問、回答が何であるか、メディア タイプが何であるかがわかり、Web サイトはそれらへのリンクを提供します。REST API も同じことを行う必要があります。人々が REST がどうあるべきかと考える方法で Web を設計するとしたら、質問と回答へのリンクがあるホームページではなく、質問を表示するには URI を取得し
stackoverflow.com/questions/<id>、 id を Question.id に置き換えてブラウザーに貼り付ける必要があることを説明する静的ドキュメントがあるでしょう。これはナンセンスですが、多くの人が REST をそう考えているのです。
この最後の点は、いくら強調してもしすぎることはありません。クライアントがドキュメント内のテンプレートから URI を構築し、リソース表現内のリンクを取得しない場合は、REST ではありません。REST の作者である Roy Fielding は、このブログ投稿でこれを明確に述べています。REST APIはハイパーテキスト駆動型でなければならない。
上記を念頭に置くと、RESTはXMLに限定されていないかもしれませんが、他の形式で正しく実行するには、リンクの形式を設計して標準化する必要があることがわかります。ハイパーリンクはXMLでは標準ですが、JSONでは標準ではありません。JSONには次のようなドラフト標準があります。ハル。
最後に、REST はすべての人に適しているわけではありません。ほとんどの人が、誤って REST と呼んでいる HTTP API で問題をうまく解決し、それ以上のことを試みないことがその証拠です。REST は、特に最初は難しいこともありますが、時間の経過とともに、サーバー側の進化が容易になり、クライアントが変更に強くなるため、その価値が高まります。何かを迅速かつ簡単に行う必要がある場合は、REST を正しく実行する必要はありません。おそらく、REST はあなたが求めているものではないでしょう。何年も、あるいは何十年もオンラインのままにしておく必要がある場合は、REST が最適です。