1. ホーム
  2. web-services

[解決済み] なぜRESTful Webサービスが必要なのか?

2022-07-11 23:13:15

疑問点

RESTfulなWebサービスを学びたいのですが(CS修士課程の一環なのでやらざるを得ないと言った方がよいでしょう)、どうすればよいでしょうか?

Wikipediaでいくつかの情報を読み、Sun Developer NetworkでRESTについての記事も読みましたが、簡単な技術ではないこと、RESTfulなアプリを作るための特別なフレームワークがあること、しばしばSOAPウェブサービスと比較され、プログラマはいつSOAPを使い、いつRESTが良いアプローチになり得るかを理解すべきことがわかりました。

数年前、SOAPは非常に人気があり(ファッショナブル?)、「SOAP」という項目がすべての良い履歴書に存在しなければならなかったことを覚えています。しかし、実際には、それは非常にまれで、非常に単純な目的を達成するために使用されました。

RESTはもうひとつの「最後の流行語」のように思えます(あるいは、私はRESTを実際に見たことがないので、完全に間違っているかもしれません)。

RESTが使われるべきで、なぜRESTなしでは同じことができないのか(あるいはRESTなしで同じことをするためにもっと多くの時間を費やさなければならないのか)、いくつかの例を挙げることはできませんか?

UPD : 残念ながら、最初のコメントでは、私の心を揺さぶるような具体的な議論が見当たりません。RESTはすごい技術なんだ!と思わせてくれるような。

このような回答が欲しいです。

私は別の複雑な HelloWorldアプリケーションを開発しています。 たくさんの/小さなデータを転送する必要があり、私は RESTソリューションを仕事仲間に提案しました。

- ああ、くそっ! ジョニー、私たちは このアプリの実装には必ずRESTを使うべきだよ このアプリの実装にRESTを使うべきだよ!

- はい、ビリー、私たちは RESTを使用することは可能ですが、より良いのは SOAPを使うべきでしょう。私はHello Worldの開発について知っているので HelloWorldアプリケーションの開発について アプリケーションの開発について知っているからです。

- しかし、SOAPは は前世紀の古臭い技術であり より良いものを使うことができます。 のものです。

- ビリー、準備はいいかい? での実験のために3日間を費やす準備ができていますか? RESTの実験に3日間費やす準備ができていますか?SOAPなら2時間でできますよ。 時間です。

- そうですね、きっと 同じセキュリティ、パフォーマンス、および 同じセキュリティ/パフォーマンス/ /スケーラビリティ/その他何でも、SOAPで達成するためにさらに多くの時間を費やすことになるでしょう。 きっと、HelloWorldアプリケーションは はRESTで開発することになるだろう。 で開発されるべきだと思います。

どのように解決するのですか?

REST は、次のようなことが非常に重要な場合に使用されるべきです。 結合を最小にする が非常に重要な場合、RESTを使うべきです。

このようなケースは、サーバが 多くの異なるクライアント によって使用される場合です。 また、以下のようなケースも考えられます。 サーバーを定期的に更新する クライアントソフトウェアを更新する必要がない場合です。

この低レベルの結合を達成することは、断言してもよいでしょう。 簡単なことではありません。 . 成功するためには、RESTのすべての制約に従うことが重要です。 純粋にステートレスな接続を維持することは困難です。 正しいメディアタイプを選択し、データをそのフォーマットに押し込むことは厄介です。 独自のメディアタイプを作成することはさらに困難です。

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

困難にもかかわらず、利点は、HTTPプロトコルの一貫した使用により、クライアント開発者が容易に理解できるはずのサービスがあることです。 このサービスは ハイパーメディアにより簡単に発見できる であり、クライアントは極めて サーバーの変更に強い .

ハイパーメディアの利点とセッション状態の回避により、ロードバランシングがシンプルになり サービスパーティショニングが可能になります。 . HTTP の規則に厳密に準拠することで、デバッガやキャッシュプロキシなどのツールが利用可能になり、素晴らしいことです。

更新

<ブロッククオート

RESTはもう一つの ファッションの最後の言葉」だと思います。 完全に間違っているかもしれません。 RESTを実際に見たことがないので、完全に間違っているかもしれません)。

SOAタイプのプロジェクトを行おうとしている人々が、SOAPスタックを使用しても約束された利益を実現できないことに気づいたため、RESTが流行しているのだと思います。 人々は、シンプルな統合方法論の例として、Webに戻り続けています。 残念ながら、人々はウェブの作成に費やされた計画と先見の明の量を過小評価しており、ウェブ上で発生するセレンディピティ的な再利用を可能にするために行われる必要があることを過度に単純化しているように思います。

あなたはRESTを実際に見たことがないと言いますが、Webブラウザを使ったことがあるなら、それはありえないことです。 Web ブラウザは REST クライアントです。

  • なぜ、誰かが HTML を変更したときにブラウザーの を更新する必要がないのはなぜですか? を変更したときに、ブラウザの更新を行う必要がないのはなぜですか?
  • なぜ、Web サイトにまったく新しいページのセットを追加することができ ページが追加され、クライアントがその新しいページにアクセスできるのはなぜですか? は、更新しなくてもその新しいページにアクセスできるのですか? を更新せずにアクセスできるのはなぜですか?
  • なぜ service-description-language" を提供する必要がないのはなぜですか? を Web ブラウザーに提供する必要がないのはなぜですか? を提供する必要はありません。 http://example.org/images/cat となります。 の場合、返り値はJPEG画像になります。 に移動すると http://example.org/description/cat の場合、return typeはtext/htmlになりますか?
  • なぜ Web ブラウザを使用すると ブラウザがリリースされたときには存在しなかったサイトを ブラウザがリリースされたときには存在しなかったサイトにアクセスできるのはなぜですか? どのようにして クライアントがこれらのサイトについて知ることができるのでしょうか?

これらは無意味な質問に聞こえるかもしれませんが、もし答えがわかれば、RESTが何であるかがわかるようになります。 REST の利点については、StackOverflow を見てください。 質問を見ているときに、そのページをブックマークしたり URLを友人に送る を送ると、その人も同じ情報を見ることができます。 彼は、その質問を見つけるためにサイト内を移動する必要はありません。

StackOverflowは認証に様々なOpenIdサービス、アバター画像にgravatar.com、分析情報にGoogle-analyticsとQuantserveを使用しています。 このような複数企業の統合は SOAP の世界では夢物語です。 . 最も良い例の1つは、StackOverflow UIを駆動するために使用されるjQueryライブラリは、GoogleのContent Delivery Networkから取得されるという事実です。 SO がクライアント (つまり Web ブラウザ) に、パフォーマンスを向上させるためにサードパーティのサイトからコードをダウンロードするように指示できるという事実は、Web クライアントとサーバー間の低結合を証明するものです。

これらは、REST アーキテクチャが機能している例です。

現在、いくつかのWebサイト/アプリケーションでは RESTのルールを破っている で、ブラウザが期待通りに動作しないことがあります。

  • 悪名高い 戻るボタン問題 は、サーバーサイドの セッションの状態を使用しているためです。
  • ロードバランシングは ロードバランシングは、サーバーサイドのセッションステートを持っている場合、面倒になります。
  • Flash アプリケーションでは、しばしば URL が具体的に 表現を特定できないようにします。
  • ウェブブラウザを破損させるもうひとつの問題は ブラウザを破壊するもうひとつの問題は メディアタイプの標準に準拠していないことです。私たちはいつも IE6 を殺すべきだという話はよく聞きます。 を殺すべきだという話をよく耳にします。 そこで問題になるのは 規格がきちんと守られていなかったこと。 または、何らかの理由で無視されたことです。
  • ログイン セッションの使用は 多くのセキュリティホールの原因となっています。

RESTはどこにでもあります。 それはWebをうまく機能させる部分です。 もしあなたが、Webのように拡張でき、Webのように変化に強く、Webが行ってきたように再利用を促進する分散アプリケーションを作りたいなら、彼らがWebブラウザを作ったときと同じルールに従えばいいのです。