RESTful Webサービスが必要なのはなぜですか？

RESTfulなWebサービスについて学びます（CS修士課程プログラムの一部であるため、これを行う必要があると言ったほうがいいでしょう）。

私はウィキペディアでいくつかの情報を読んだり、Sun Developer NetworkでRESTに関する記事を読んだりしましたが、それは簡単な技術ではなく、RESTfulアプリを構築するための特別なフレームワークがあり、SOAP Webサービスやプログラマーは、SOAPをいつ使用し、RESTが優れたアプローチになる可能性があることを理解する必要があります。

数年前、SOAPは非常に人気があり（ファッショナブル？）、アイテム「SOAP」はすべての優れたCVに存在しなければならなかったことを覚えています。しかし実際には、それは非常にまれに使用され、非常に単純な目的を達成するために使用されました。

RESTはもう1つの「ファッションの最後の言葉」であるように見えます（または、RESTを実際に見たことがないので、私は完全に間違っている可能性があります）。

RESTを使用する必要があった理由と、RESTなしでは同じことができない理由（またはRESTなしで同じことを行うためにより多くの時間を費やす必要がある理由）をいくつか教えてください。

UPD：残念ながら、最初のコメントで私を驚かせるような具体的な議論はありません。RESTは素晴らしいテクノロジーだと私に思わせてください！

私はこのような答えを見たいのですが：

私は別の複雑なHelloWorldアプリケーションを開発していて、大量の/小さなデータを転送する必要があるので、同僚にRESTソリューションを提案しました。

- くそっ！ジョニー、このアプリの実装には必ずRESTを使用する必要があります。
–はい、ビリー。RESTを使用できますが、SOAPを使用する方が適切です。HelloWorldアプリケーションの開発について何か知っているので、私を信じてください。
–しかし、SOAPは前世紀の昔ながらのテクノロジーであり、より優れたテクノロジーを使用できます。
–ビリー、RESTを試すために3日間を費やす準備ができていますか？SOAPを使用すると、2時間でこれを実行できます。–
はい、SOAPを使用して他の同じセキュリティ/パフォーマンス/ /スケーラビリティ/その他を実現するために、さらに多くの時間を費やすと確信しています。これからは、HelloWorldアプリケーションをRESTでのみ開発するべきだと私は確信しています。

分散アプリケーションでクライアントコンポーネントとサーバーコンポーネント間の結合を最小限に抑えることが非常に重要な場合は、RESTを使用する必要があります。

これは、ユーザーが制御できない多くの異なるクライアントによってサーバーが使用される場合に当てはまります。また、クライアントソフトウェアを更新せずにサーバーを定期的に更新できるようにする必要がある場合もあります。

この低レベルのカップリングを実現するのは簡単ではないことは確かです。成功するには、RESTのすべての制約に従うことが重要です。純粋にステートレスな接続を維持することは困難です。適切なメディアタイプを選択し、データをフォーマットに圧縮するのは難しい作業です。独自のメディアタイプを作成することはさらに困難です。

リッチサーバーの動作を統一されたHTTPインターフェースに適合させることは混乱を招く可能性があり、比較的単純なRPCアプローチと比較すると、時々奇妙に見えます。

困難にもかかわらず、利点は、HTTPプロトコルの一貫した使用により、クライアント開発者が簡単に理解できるはずのサービスがあることです。ハイパーメディアにより、サービスは簡単に検出可能であり、クライアントはサーバーでの変更に対して非常に回復力がある必要があります。

ハイパーメディアの利点とセッション状態の回避により、負荷分散が簡単になり、サービスのパーティション化が実現可能になります。HTTPルールに厳密に準拠しているため、デバッガーやキャッシュプロキシなどのツールを利用できるのはすばらしいことです。

更新

RESTはもう1つの「ファッションの最後の言葉」であるように見えます（または、RESTを実際に見たことがないので、私は完全に間違っている可能性があります）。

SOAタイプのプロジェクトを行おうとする人々が、SOAPスタックを使用しても、約束された利点を実現していないことに気付いたため、RESTはファッショナブルになったと思います。人々は、単純な統合方法論の例としてWebに戻り続けています。残念ながら、人々はWebの作成に費やした計画と予測の量を過小評価しており、Web上で発生する一種の偶発的な再利用を可能にするために必要なことを単純化しすぎていると思います。

実際にはRESTを見たことがないとおっしゃっていますが、Webブラウザーを使用する場合は、それが本当の可能性はありません。WebブラウザーはRESTクライアントです。

• 誰かがWebサイトのHTMLを変更したときに、ブラウザを更新する必要がないのはなぜですか。
• 完全な新しいページのセットをWebサイトに追加しても、「クライアント」が更新なしでそれらの新しいページにアクセスできるのはなぜですか？
• Webブラウザーに「service-description-language」を提供して、http：//example.org/images/catに移動したときに、戻り値の型がjpeg画像になること を通知する必要がないのはなぜですか。http://example.org/description/cat 戻り値の型は、text / htmlのでしょうか？
• ブラウザーがリリースされたときに存在しなかったサイトにWebブラウザーを使用してアクセスできるのはなぜですか？クライアントはこれらのサイトについてどのように知ることができますか？

これらは非常に難しい質問のように聞こえるかもしれませんが、答えがわかっている場合は、RESTの概要を確認できます。RESTのその他の利点については、StackOverflowをご覧ください。質問を見ているときに、そのページをブックマークしたり、URLを友達に送信したりすると、同じ情報を見ることができます。その質問を見つけるためにサイトをナビゲートする必要はありません。

StackOverflowは、認証にはさまざまなOpenIdサービス、アバター画像にはgravatar.com、分析情報にはgoogle-analyticsおよびQuantserveを使用します。この種の複数企業の統合は、SOAPの世界だけが夢見るタイプのことです。最良の例の1つは、StackOverflow UIの駆動に使用されるjQueryライブラリがGoogleのコンテンツ配信ネットワークから取得されることです。SOがクライアント（つまりWebブラウザー）にサードパーティのサイトからコードをダウンロードしてパフォーマンスを向上させることができるという事実は、Webクライアントとサーバー間の結合が低いことを証明しています。

これらは作業中のRESTアーキテクチャの例です。

現在、一部のWebサイト/アプリケーションはRESTの規則に違反しており、ブラウザーは期待どおりに機能しません。

• 悪名高い[ 戻る]ボタンの問題 は、サーバー側のセッション状態の使用が原因で発生します。
• サーバー側のセッション状態があると、負荷分散が面倒になる可能性があります。
• Flashアプリケーションでは、URLが表現を明確に識別できないことがよくあります。
• Webブラウザーを破壊するもう1つの問題は、メディアタイプの標準への適合性が低いことです。IE6をどのように殺す必要があるかについて、いつも耳にします。問題は、基準が適切に守られなかったか、何らかの理由で無視されたことです。
• ログインセッションの使用は、多くのセキュリティホールの原因です。

RESTはどこにでもあります。うまく機能するのはウェブの一部です。Webのように拡張できる分散アプリケーションを構築したい場合は、Webのように変更できるように弾力性を持ち、Webのように再利用を促進します。次に、Webブラウザーの構築時と同じルールに従います。

RESTは、私の知る限り、Roy Fieldingの論文のArchitectural StylesとDesign of Network-based Software Architecturesによって開始されました。

論文の上部には引用があります：

ほとんど誰もが自然との平和を感じます。風に吹かれたヒースで、芝生のフィールドで、まだ湖のそばで、海岸に対して海の波を聞く。いつか私たちが再び時代を超えた方法を学んだとき、私たちは私たちの町について同じことを感じ、今日私たちが海を歩いたり、長い草の中で伸びたりしているように、私たちは彼らの中で平和を感じます。牧草地。

—クリストファー・アレクサンダー、時代を超越した建築の方法（1979）

そして、それは本当にそこに要約されます。RESTは多くの点でよりエレガントです。

SOAPはHTTPをベースにしたプロトコルであるため、SOAPで新しい規則を構築するために多くのHTTP規則をバイパスし、さまざまな点でHTTPと冗長です。ただし、HTTPは、HTTPを介して情報を取得、検索、書き込み、削除するのに十分であり、それがRESTの多くのものです。RESTは、その上にではなくHTTPを使用して構築されているため、RESTと統合したいソフトウェア（Webブラウザーなど）は、SOAPを理解する必要がなく、HTTPだけを使用する必要があります。この時点で広く使用されており、統合プロトコルが使用されています。

ここから：

RESTの利点：

• 軽量-余分なxmlマークアップが少ない
• 人間が読める結果
• 構築が簡単-ツールキットは不要

これもチェックしてください：

公平に言うと、RESTはすべてのWebサービスに最適なソリューションではありません。セキュリティで保護する必要があるデータは、URIのパラメーターとして送信しないでください。また、詳細な注文書にあるような大量のデータは、すぐに煩雑になったり、URIの範囲外になったりする可能性があります。このような場合、SOAPは確かに確かなソリューションです。ただし、最初にRESTを試し、必要な場合にのみSOAPを使用することが重要です。これにより、アプリケーション開発をシンプルでアクセスしやすい状態に保つことができます。

私はこれを初心者として理解するのに多くの時間を費やしたと言っても間違いありませんが、これはRESTをゼロから始めるのに最適なリンクです！ http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

あなたを引き込むためだけに

「従来のWebサービス」とは何かを考えてください。公開された「メソッド」とのインターフェースです。クライアントはメソッドの名前、入力、出力を知っているため、それらを呼び出すことができます。

ここで、「メソッド」を公開しないインターフェースを想像してみてください。代わりに、「オブジェクト」を公開します。したがって、クライアントがこのインターフェースを見るとき、それが見るすべては1つ以上の「オブジェクト」です。「オブジェクト」には「何もしない」ため、入出力はありません。動詞ではなく名詞です。それは「もの」であり、「行動」ではありません。

たとえば、都市に提供する場合、現在の気象条件を提供する従来のWebサービスを考えてみてください。おそらくGetWeatherInfo（）のようなWebメソッドがあり、都市を入力として取り、気象データを出力として提供します。これまでのところ、クライアントがこのWebサービスをどのように使用するかを理解するのは簡単です。

上記のWebサービスの代わりに、都市をオブジェクトとして公開する新しいサービスがあるとします。したがって、GetWeatherInfo（）の代わりにクライアントとして見ると、ニューヨーク、ダラス、ロサンゼルス、ロンドンなどが表示されます。そして、これらの都市には、アプリケーション固有のメソッドがぶら下がっていません-それらは明らかに不活性ガスのようです-それら自体は反応しません。

あなたは考えている必要があります。まあ、それはクライアントとして、ダラスの天候にたどり着くのにどのように役立ちますか。それについては、しばらくしてから説明します。

Webサービスから取得するすべてが「オブジェクトのセット」である場合、明らかに「それらに作用する」方法が必要です。オブジェクト自体には呼び出すメソッドがないため、これらのオブジェクトに適用できる一連のアクションが必要です。つまり、「名詞に動詞を適用する」必要があります。「名詞」であるリンゴなどのオブジェクトが表示された場合は、「食べる」などの「動詞」を適用できます。ただし、すべての動詞がすべての名詞に適用できるわけではありません。同様に、車は運転できますが、テレビは運転できません。

したがって、Webサービスがオブジェクトのみを公開していて、質問された場合は、「すべてのクライアントが表示するすべてのオブジェクトに適用できる」という標準のアクションまたは動詞をいくつか設計してみましょう。

ここにいくつかのアイデアがあります：

• RESTは、統一されたインターフェースを使用するようにサービスを制限します。サービスが機能する可能性のあるすべての方法について、空想にふける（または議論する）時間を無駄にする必要はありません。システム内のリソースを特定するために正しく作業することができます。それ自体が大きな仕事であることがわかりますが、幸いなことに、問題はより明確に定義される傾向があります。
• リソース、それらの関連付け、およびそれらの表現を手に入れれば、多くの決定があなたのためになされているので、サービスを実装するために行うことは本当にほとんどありません。
• システムは他のRESTfulシステムと非常によく似たものになります。チームメイト、パートナー、クライアントの学習曲線が減少します。
• 他の開発者や技術的な知識のない開発者（顧客など）とでも設計の問題について話し合うための共通の語彙があります。
• Darrelが言うように、ハイパーテキスト駆動の設計を使用しているので、サービスは結合の範囲を1つだけに絞り込みます-メディアタイプ。システムへの変更は狭い範囲の連絡先に含まれるため、これは開発者として役立ちます。これにより、コードを壊す変更が少なくなるという点でクライアントを支援します。
• RESTの実装で発生する可能性のあるほとんどすべての問題は、新しいリソースを公開するか、リソースモデルを再考することで解決できます。この焦点は、IMO、生産性の大幅な向上です。

結論として、RESTはチームのワークフローから、最も時間のかかる問題の多い設計と実装の決定の多くを取り除きます。それはあなたの注意をあなたのサービスの実装からそれを設計することに移します。そして、HTTPプロトコルにgobbledygookを積み上げることなくそれを行います。

RESTに関する「プロ」の答えのほとんどは、タスクに適切なツールを提供する環境を使用してSOAP Webサービスまたはクライアントを開発したことがない人からのものであるようです。彼らは、Visual Studio .NETとIBMのRational Web Developerを使用して、私が単に遭遇したことのない問題について不満を述べています。スクリプトサービスや、ツールのサポートがほとんどまたはまったくない他の言語でWebサービスまたはクライアントを開発する必要がある場合、これらは正当な苦情だと思います。

また、いくつかの「プロ」ポイントが実際には真実であるように聞こえることを認めなければなりません。しかし、それらの価値を示す例を見たことがありません。特に、REST Webサービスの良い例へのリンクを含むコメントを誰かが投稿していただければ幸いです。これは、おそらく階層内で複数レベルのリソースを使用し、メディアタイプを適切に使用するものである必要があります。多分良い例を見ればわかるだろう。その場合、私はここに戻ってそれを認めるだろう。

私がRESTサービスを使用している理由がすでに与えられている回答に少し平凡なスピンを追加するには、私があなたがビジネスパートナーにURLを渡すことができ、見返りにXMLの適切にレイアウトされたスラブを受け取ることがわかっている場合です彼らが.Net xx、PHP、Python、Java、Ruby、またはgod-knowsで作業しているかどうかに関係なく、頭痛を大幅に軽減します。

それはまた、技術的でない側では、営業担当者が完全なマペットのように見えることを恐れることなく、多目的なAPIを自慢できることも意味します。

技術的なメリットとは別に、技術者以外が簡単に説明し、実証し、自信を持って感じることは何でも良いことです。SOAPは、技術者にとってはクールなのと同じように、非技術者によるアプローチがはるかに難しいため、「販売」するのは簡単ではありません。

非技術者が頭を丸くすることができるものがこだわりがちであることに気づきがちです。したがって、RESTはSOAPのようにファッションの気まぐれに影響を受けやすいとは思えません。

しかし、RESTサービスにロックダウンする必要のあるものを何も入れないことに関するすべてのことは、技術があまり技術的に理解されていない人々によって非常に簡単に理解されるという理由だけでさえ、真実です。

RESTは、ネットワークアプリケーションを設計するためのアーキテクチャスタイルです。考え方は、CORBA、RPC、SOAPなどの複雑なメカニズムを使用してマシン間を接続するのではなく、単純なHTTPを使用してマシン間で呼び出しを行うというものです。

多くの点で、HTTPに基づくWorld Wide Web自体はRESTベースのアーキテクチャと見なすことができます。RESTfulアプリケーションはHTTPリクエストを使用して、データの投稿（作成や更新）、データの読み取り（クエリの作成など）、データの削除を行います。したがって、RESTは4つのCRUD（作成/読み取り/更新/削除）操作すべてにHTTPを使用します。

RESTは、RPC（リモートプロシージャコール）やWebサービス（SOAP、WSDLなど）のようなメカニズムの軽量な代替手段です。後で、RESTがいかにシンプルかを見ていきます。

RESTは単純ですが、十分な機能を備えています。基本的に、RESTfulアーキテクチャーでは実行できないWebサービスでできることは何もありません。RESTは「標準」ではありません。たとえば、RESTに対するW3Cの推奨事項はありません。また、RESTプログラミングフレームワークはありますが、RESTの操作は非常に簡単なので、Perl、Java、C＃などの言語の標準ライブラリ機能を使用して「独自にロール」することができます。