[解決済み] SOAPとRESTの比較（相違点）

質問

Webサービスの通信プロトコルとして、SOAPとRESTの違いについての記事を読みましたが、SOAPに対するRESTの最大のメリットは何だと思いますか。

1. RESTはよりダイナミックで、UDDI（Universal Description, Discovery, and Integration）の作成と更新は必要ありません。

2. RESTはXML形式のみに限定されるものではありません。RESTfulなウェブサービスは、プレーンテキスト/JSON/XMLを送信することができます。

しかし、SOAPの方がより標準化されています（例：セキュリティ）。

ということで、これらの点は正しいのでしょうか？

解決方法は？

残念ながら、RESTの周辺には、誤った情報や誤解が多く存在します。ご質問の内容だけでなく cmdの回答 Stack Overflowにあるこのテーマに関する質問と回答のほとんどが、それを反映しています。

SOAPとRESTは直接比較することはできません。前者はプロトコルであり（少なくともそうであろうとしている）、後者はアーキテクチャのスタイルだからです。SOAPでないHTTP APIをRESTと呼ぶ傾向があるので、これが混乱の原因の1つでしょう。

SOAPとRESTの主な違いは、クライアントとサーバーの実装がどの程度結合しているかです。SOAPクライアントは、カスタムデスクトップアプリケーションのように動作し、サーバーと緊密に結合しています。クライアントとサーバーの間には厳格な契約があり、どちらかが何かを変更すると、すべてが壊れることが予想されます。変更後は常に更新が必要ですが、契約が守られているかどうかを確認するのは簡単です。

RESTクライアントは、どちらかというとブラウザに近いものです。プロトコルと標準化されたメソッドの使い方を知っている汎用的なクライアントで、アプリケーションはその中に収まるようにしなければなりません。余分なメソッドを作成してプロトコル標準に違反するのではなく、標準的なメソッドを活用して、メディアタイプに応じたアクションを作成するのです。正しく行われれば、カップリングは少なくなり、変更にもより優雅に対応できるようになります。クライアントは、エントリーポイントとメディアタイプを除いて、APIについて全く知らない状態でRESTサービスに入ることが想定されている。SOAPでは、クライアントは使用するものすべてについて事前の知識が必要で、さもなければ対話を開始することさえできない。さらに、RESTクライアントは、サーバー自体から提供されるコードオンデマンドによって拡張することができます。典型的な例は、クライアント側で別のサービスとの対話を推進するために使用されるJavaScriptコードです。

以上が、RESTがどういうものか、SOAPとどう違うのかを理解するための重要なポイントだと思います。

• RESTはプロトコルに依存しない。HTTPと連動しているわけではありません。ウェブサイト上のftpリンクをたどれるのと同じように、RESTアプリケーションは標準化されたURIスキームがあれば、どんなプロトコルでも使うことができるのです。

• RESTは、CRUDをHTTPメソッドにマッピングしたものではありません。読む これ の回答で詳しく説明しています。

• RESTは使っているパーツと同じように標準化されています。HTTPのセキュリティと認証は標準化されているので、HTTPでRESTを行う場合はそれを使うことになります。

• がなければRESTはRESTではありません。 ハイパーメディア と HATEOAS . つまり、クライアントはエントリーポイントのURIしか知らず、リソースはクライアントがたどるべきリンクを返すことになっているのです。REST APIでできることすべてにURIパターンを与えるような空想的なドキュメントジェネレータは、完全にポイントを外している。彼らは標準に従うはずのものを文書化しているだけでなく、そうすると、クライアントをAPIの進化のある特定の瞬間に結びつけていることになり、API上のどんな変更も文書化し適用しなければならず、さもなければ壊れてしまうのである。

• RESTは、Webのアーキテクチャスタイルそのものです。Stack Overflowに入ると、ユーザー、質問、回答が何であるか、メディアの種類がわかり、ウェブサイトはそれらへのリンクを提供します。REST APIは同じことをしなければならない。もし私たちがRESTを行うべきだと考える方法でウェブをデザインした場合、QuestionとAnswerへのリンクを持つホームページを持つ代わりに、質問を見るためにURIを取る必要があることを説明する静的なドキュメントを持っているでしょう stackoverflow.com/questions/<id> のように、idをQuestion.idに置き換えて、ブラウザに貼り付けてください。ナンセンスですが、多くの人がRESTをそう思っているのです。

この最後のポイントは、いくら強調してもしきれません。クライアントがドキュメントのテンプレートからURIを構築し、リソース表現にリンクを得られないのであれば、それはRESTではありません。RESTの作者であるRoy Fieldingは、このブログ記事でそれを明言しています。 REST APIはハイパーテキスト駆動型でなければならない .

以上のことから、RESTはXMLに限定されないかもしれませんが、他のフォーマットで正しく行うには、リンクのための何らかのフォーマットを設計し、標準化する必要があることに気づかれるでしょう。ハイパーリンクはXMLでは標準的ですが、JSONではそうではありません。JSONには、次のような標準の草案があります。 HAL .

最後に、RESTは万人向けではありません。その証拠に、ほとんどの人がRESTと間違えて呼んだHTTP APIで非常にうまく問題を解決し、それ以上の冒険をすることはないでしょう。RESTは時々、特に最初のうちは難しいですが、サーバー側の進化が容易になり、クライアントの変化への耐性が高まることで、時間をかけて報われるのです。もし、何かを素早く簡単に行う必要があるのなら、RESTを正しく理解することに頭を悩ませる必要はないでしょう。おそらく、あなたが求めているものはそれではないでしょう。何年も、あるいは何十年もオンラインでなければならないものが必要な場合は、RESTが適しています。