私は RESTful Web サービスを学習するつもりです (これは CS 修士課程の一部なので、これをやらなければならないと言った方が適切でしょう)。
私は Wikipedia でいくつかの情報を読み、また Sun Developer Network で REST に関する記事を読みました。REST は簡単な技術ではなく、RESTful アプリを構築するための特別なフレームワークがあり、SOAP Web サービスと比較されることが多く、プログラマーは SOAP を使用するタイミングと REST が適切なアプローチになるタイミングを理解する必要があることがわかりました。
数年前、SOAP が非常に人気があり (流行っていた?)、優れた履歴書には必ず「SOAP」という項目が含まれていたことを覚えています。しかし、実際には、SOAP が使用されることはほとんどなく、非常に単純な目的にのみ使用されていました。
REST はもう 1 つの「流行の最後の言葉」であるように私には思えます (あるいは、実際に REST を見たことがないので、私が完全に間違っている可能性もあります)。
REST を使用すべき例と、REST なしで同じことができない理由 (または、REST なしで同じことを行うのに多くの時間を費やす必要がある理由) をいくつか挙げていただけますか?
上院: 残念ながら、最初のコメントでは私を驚かせるような具体的な議論は見当たりません。REST は素晴らしいテクノロジーだと思わせてくれます!
次のような回答を期待しています:
私は別の複雑な HelloWorld アプリケーションを開発しており、大量の / 小さなデータを転送する必要があり、同僚に REST ソリューションを提案しました。
– ああ、大変！ジョニー、このアプリを実装するには間違いなく REST を使うべきだね！
– そうだね、ビリー、REST は使えるけど、SOAP を使ったほうがいい。HelloWorld アプリケーションの開発について多少は知っているから、信じてくれよ。
– でも、SOAP は前世紀の古い技術だし、もっといい技術を使えるはずだ。
– ビリー、REST の実験に 3 日費やす覚悟はある？SOAP なら 2 時間でできるよ。
– そうだね、SOAP で同じセキュリティ/パフォーマンス/スケーラビリティ/その他すべてを実現するには、もっと時間がかかると思う。HelloWorld アプリケーションは、これからは REST だけで開発すべきだと思う。
ベストアンサー1
RESTは、非常に重要な場合に使用してください。カップリングを最小限に抑える分散アプリケーション内のクライアント コンポーネントとサーバー コンポーネント間。
これは、サーバーが次のような目的で利用される場合に当てはまる可能性があります。さまざまなクライアントあなたがコントロールできないもの。また、あなたがコントロールできるようにしたい場合も、サーバーを定期的に更新するクライアント ソフトウェアを更新する必要はありません。
この低レベルの結合を達成することは簡単ではない成功するには、REST のすべての制約に従うことが重要です。完全にステートレスな接続を維持するのは困難です。適切なメディア タイプを選択し、データをその形式に押し込むのは困難です。独自のメディア タイプを作成するのはさらに困難です。
豊富なサーバー動作を統一された HTTP インターフェイスに適応させるのは混乱を招きやすく、比較的単純な RPC アプローチと比較すると、時には杓子定規に思えることもあります。
困難にもかかわらず、HTTPプロトコルを一貫して使用することで、クライアント開発者が簡単に理解できるサービスが提供されるという利点があります。サービスはハイパーメディアにより簡単に発見可能そしてクライアントは非常にサーバーの変更に耐性がある。
ハイパーメディアの利点とセッション状態の回避により、負荷分散が簡単になり、サービス分割は実行可能HTTP ルールに厳密に準拠しているため、デバッガーやキャッシュ プロキシなどのツールを利用できるのは非常に便利です。
アップデート
REST はもう 1 つの「流行の最後の言葉」であるように私には思えます (あるいは、実際に REST を見たことがないので、私が完全に間違っている可能性もあります)。
REST が流行したのは、SOA タイプのプロジェクトを実行しようとしている人々が、SOAP スタックを使用すると約束されたメリットが得られないことに気付いたからだと思います。人々は、シンプルな統合方法の例として Web に頼り続けています。残念ながら、人々は Web の作成に費やされた計画と先見の明を過小評価し、Web で実際に起こるような偶然の再利用を可能にするために必要なことを単純化しすぎていると思います。
REST を実際に見たことがないとおっしゃっていますが、Web ブラウザを使用したことがあるのであれば、それはあり得ません。Web ブラウザは REST クライアントです。
- 誰かが Web サイトの HTML を変更したときに、ブラウザを更新する必要がないのはなぜですか?
- 完全に新しいページのセットを Web サイトに追加しても、「クライアント」は更新せずにそれらの新しいページにアクセスできるのはなぜですか?
- なぜ、ウェブブラウザに「サービス記述言語」を提供して、いつアクセスするかを伝える必要がないのでしょうか？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 アーキテクチャが実際に機能している例です。
現在、一部のウェブサイトやアプリケーションではRESTのルールを破るブラウザは期待どおりに動作しなくなります。
- 悪名高い戻るボタンの問題サーバー側のセッション状態を使用することで発生します。
- サーバー側のセッション状態がある場合、負荷分散が困難になる可能性があります。
- Flash アプリケーションでは、多くの場合、URL が表現を具体的に識別できないようになっています。
- Web ブラウザを台無しにするもう 1 つの問題は、メディア タイプの標準への準拠が不十分であることです。IE6 を廃止する必要があるという話はよく聞きます。問題は、標準が適切に遵守されていないか、何らかの理由で無視されていることです。
- ログイン セッションの使用は多くのセキュリティ ホールの原因となります。
REST はどこにでもあります。Web をうまく機能させる要素です。Web のように拡張でき、Web のように変更に強く、Web のように再利用を促進する分散アプリケーションを構築したい場合は、Web ブラウザーを構築したときと同じルールに従ってください。