なぜRESTful Webサービスが必要なのですか？
RESTfulなWebサービスについて学習します（CS修士課程プログラムの一部であるため、これを行う必要があると言った方が良いでしょう）。
ウィキペディアでいくつかの情報を読み、Sun Developer NetworkでRESTに関する記事も読みました。簡単な技術ではなく、RESTfulアプリを構築するための特別なフレームワークがあります。 SOAPと比較すると、WebサービスとプログラマはSOAPをいつ使用し、RESTがナイスアプローチになるかを理解する必要があります。
数年前、SOAPは非常に人気があり（流行？）、アイテム「SOAP」はすべての良い履歴書に存在しなければならなかったことを覚えています。しかし、実際には非常にまれに使用され、非常に単純な目的を達成するために使用されました。
RESTはもう1つの「ファッションの最後の言葉」であるように思えます（または実際にRESTを見たことがないので、まったく間違っている可能性があります）。
RESTを使用する必要がある例と、RESTなしで同じことができない理由（または、RESTなしで同じことをするためにもっと多くの時間を費やす必要がある理由）を教えてください？
[〜＃〜] upd [〜＃〜]：残念ながら、最初のコメントで心を打つような具体的な議論は見当たらない。 RESTは素晴らしいテクノロジーだと思わせてください！
私はこのような答えを見たいです：
私は別の複雑なHelloWorldアプリケーションを開発していたので、大量の小さなデータを転送する必要があり、同僚にRESTソリューションを提案しました。
- くそっ！ジョニー、このアプリの実装には必ずRESTを使用すべきです！
–はい、ビリー、RESTを使用できますが、SOAPを使用した方がよいでしょう。 HelloWorldアプリケーションの開発について何か知っているからです。
–しかし、SOAPは前世紀の昔ながらのテクノロジーであり、より良いものを使用できます。
–ビリー、RESTの実験に3日間を費やす準備はできていますか？これは2時間でSOAPで行えます。
–はい、SOAPで同じセキュリティ/パフォーマンス//スケーラビリティ/その他を達成するために、さらに多くの時間を費やすことになると確信しています。 HelloWorldアプリケーションは、今からRESTでのみ開発されるべきだと確信しています。
分散アプリケーションのクライアントコンポーネントとサーバーコンポーネント間の結合を最小化するが非常に重要な場合は、RESTを使用する必要があります。
これは、あなたが制御できない多くの異なるクライアントによってサーバーが使用される場合です。クライアントソフトウェアを更新せずにサーバーを定期的に更新できるようにしたい場合にも当てはまります。
この低レベルのカップリングを達成することはするのは簡単ではありませんです。成功するには、RESTのすべての制約に従うことが重要です。純粋にステートレスな接続を維持することは困難です。適切なメディアタイプを選択し、データをフォーマットに圧縮するのは困難です。メディアタイプはさらに難しくなる可能性があります。
リッチサーバーの動作を統一されたHTTPインターフェイスに適合させることは、混乱を招く可能性があり、比較的単純なRPCアプローチと比較すると、時には大胆に見えます。
困難にもかかわらず、利点は、HTTPプロトコルの一貫した使用により、クライアント開発者が簡単に理解できるサービスがあることです。サービスはハイパーメディアにより簡単に検出可能であり、クライアントは非常にサーバーの変更に対する回復力である必要があります。
ハイパーメディアの利点とセッション状態の回避により、負荷分散が簡単になり、サービスの分割が可能になります。 HTTPルールに厳密に準拠しているため、デバッガーやキャッシュプロキシなどのツールの可用性は素晴らしいものになります。
更新
RESTはもう1つの「ファッションの最後の言葉」であるように思えます（または、実際にREST 。
REST=が流行しているのは、人々がSOAタイプのプロジェクトを試みると、SOAP人々は単純な統合方法論の例としてウェブに戻り続けていますが、残念ながら、人々はウェブの作成に費やされた計画と先見の量を過小評価し、何をする必要があるかを単純化しすぎていると思います。ウェブ上で発生する一種の偶然の再利用を許可します。
あなたは実際にRESTを見たことがないと言いますが、Webブラウザーを使用する場合、それはおそらく真実ではありません。WebブラウザーはRESTクライアント。
- 誰かがWebサイトのhtmlを変更したときに、ブラウザーを更新する必要がないのはなぜですか？
- まったく新しいページセットをWebサイトに追加しても、「クライアント」が更新せずにそれらの新しいページにアクセスできるのはなぜですか？
- なぜhttp://example.org/images/catに行くかを伝えるためにWebブラウザに「サービス記述言語」を提供する必要がないのはなぜですか=戻り値の型はjpeg画像になり、http://example.org/description/catに移動すると、戻り値の型はtext/htmlになりますか？
- Webブラウザーを使用して、ブラウザーのリリース時に存在しなかったサイトにアクセスできるのはなぜですか？クライアントはこれらのサイトについてどのように知ることができますか？
これらは無分別な質問のように聞こえるかもしれませんが、答えを知っていれば、RESTが何であるかを見ることができます。RESTのその他の利点についてはStackOverflowをご覧ください。質問、そのページをブックマークするか友人にURLを送信すると、同じ情報を見ることができます。彼はその質問を見つけるためにサイトをナビゲートする必要はありません。
StackOverflowはさまざまなOpenIdサービスを認証に使用し、gravatar.comをアバター画像に使用し、google-analyticsとQuantserveを分析情報に使用します。このような複数企業の統合は、SOAP世界のみが夢見ているのタイプです。最良の例の1つは、jQueryライブラリがStackOverflow UIがGoogleのContent Delivery Networkから取得されます。SOは、パフォーマンスを改善するためにサードパーティのサイトからコードをダウンロードするようにクライアント（つまり、Webブラウザー）に指示することができます。 Webクライアントとサーバー間の低結合。
これらはREST作業中のアーキテクチャの例です。
現在、一部のWebサイト/アプリケーションはRESTの規則に違反し、ブラウザーが期待どおりに動作しません。
- 悪名高い戻るボタンの問題は、サーバー側のセッション状態を使用していることが原因です。
- サーバー側のセッション状態があると、負荷分散が苦痛になることがあります。
- 多くの場合、Flashアプリケーションは、URLが表現を明確に識別できないようにします。
- Webブラウザーを壊すもう1つの問題は、メディアタイプ標準への適合性の低さです。 IE6をどのように殺す必要があるかについて、私たちは常に耳にします。そこにある問題は、標準が適切に守られなかったか、何らかの理由で無視されたことです。
- ログインセッションの使用は、多くのセキュリティホールの原因です。
RESTはどこにでもあります。うまく機能するのはウェブの一部です。 Webのように拡張できる分散アプリケーションを構築し、Webのように変化に強くなり、Webが行ったように再利用を促進する場合は、Webブラウザーを構築するときと同じルールに従います。
私の知る限り、RESTはRoy Fieldingの論文 アーキテクチャースタイルとネットワークベースのソフトウェアアーキテクチャの設計 で開始されました。これは、見ていない人にとっては読む価値があります。
論文の冒頭に引用があります：
ほとんどすべての人が自然との平和を感じています：海岸に打ち寄せる海の波、静かな湖、草地、風に吹かれたヒースに耳を傾けます。ある日、私たちが時代を超えた方法を再び学んだとき、私たちは自分たちの町について同じことを感じ、海を歩いたり、長い草の中に伸びたりするのと同じように、彼らに平和を感じます。牧草地
—クリストファー・アレクサンダー、不朽の建築の方法（1979）
そして、それは本当にそれをまとめています。 RESTは多くの点でよりエレガントです。
SOAPはHTTPに基づくプロトコルであるため、SOAPで新しい規則を構築するために多くのHTTP規則をバイパスし、多くの点でHTTPと重複しています。ただし、HTTPは、HTTPを介して情報を取得、検索、書き込み、および削除するには十分であり、それはRESTのことです。RESTその上ではなくHTTPで構築されているため、Webブラウザなどの統合するソフトウェアは、SOAPを理解する必要はありません。HTTPのみ、この時点で最も広く理解され、使用されているプロトコルである必要があります。
私はこれを初心者として理解するのに多くの時間を費やしたと安全に言うことができますが、これは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が言うように、あなたは hypertext-driven デザインを使用しているので、あなたのサービスは結合の範囲をただ一つのこと-メディアタイプに限定します。これは、システムの変更が狭い連絡先に含まれるため、開発者として役立ちます。これにより、クライアントがコードを壊す変更が少なくなります。
- REST=を実装する際に発生する可能性のあるほぼすべての問題は、 新しいリソースを公開する によって解決できるか、リソースモデルを再考します。ブースト。
一番下の行、RESTは、チームのワークフローから、最も時間と労力を要する設計および実装の決定の多くを削除します。これは、実装サービスをdesigningし、gobbledygookをHTTPプロトコルに重ねることなく、サービスを実行します。
RESTに関する「プロ」の回答のほとんどは、タスクに適切なツールを提供する環境を使用してSOAP Webサービスまたはクライアントを開発したことがない人から来ているようです。彼らは、Visual Studio .NETとIBMのRational Web Developerを使用して、私が一度も遭遇したことのない問題について文句を言います。スクリプト言語、またはツールをほとんどまたはまったくサポートしない他の言語でWebサービスまたはクライアントを開発する必要がある場合、これらは有効な苦情であると思われます。
また、いくつかの「プロ」ポイントが実際に本当のことのように聞こえることを認めなければなりませんが、その価値を示す例を見たことはありません。特に、誰かがREST Webサービスの良い例へのリンクを含むコメントを投稿してくれたらとても感謝しています。これは、おそらく階層内の複数レベルのリソースを使用し、メディアタイプを適切に使用するものでなければなりません。たぶん、良い例を見ると理解できるでしょう。その場合、ここに戻ってそれを認めます。
REST=======================================================================戻り、.Net xx、PHP、Python、Javaで作業しているかどうかに関係なく、XMLのスラブがうまくレイアウトされているRubyまたはgod-knows-whatが頭痛を大幅に軽減します。
それはまた、非技術的な終わりに、営業担当者が完全なマペットのように見えることを恐れることなく、汎用性の高い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 is 「標準」ではありません。たとえば、RESTに対するW3C勧告はありません。また、RESTプログラミングフレームワークがある一方で、REST Perl、Java、C＃などの言語の標準ライブラリ機能を使用して「独自にロール」できることが簡単です。