私はデスクトップ開発者からWeb開発者に移行していますが、HTTPがステートレスである理由を理解するのに苦労しています。その理由は何ですか?私のようなデスクトップ開発者がステートレス開発環境に移行する方法は何ですか?
私はデスクトップ開発者からWeb開発者に移行していますが、HTTPがステートレスである理由を理解するのに苦労しています。その理由は何ですか?私のようなデスクトップ開発者がステートレス開発環境に移行する方法は何ですか?
回答:
これは私が見たステートレスインターネットの最良の説明です:
妻にRESTを説明する方法
http://www.looah.com/source/view/2284
妻:ロイ・フィールディングは誰ですか?
ライアン:誰か。彼は頭がいい。
妻:ああ?彼が何をした?
ライアン:彼は最初のWebサーバーの作成を手伝い、その後、Webがそのように機能する理由を説明するために大量の調査を行いました。彼の名前は、サーバーからブラウザにページを取得するために使用されるプロトコルの仕様にあります。
妻:どのように機能しますか?
ライアン:ウェブ?
妻:うん。
ライアン:うーん。まあ、本当にすごいことです。そして面白いのは、それがすべて非常に過小評価されていることです。私が話していたプロトコル、HTTP、それは人々が何らかの理由で無視するあらゆる種類のきちんとしたものが可能です。
妻: httpは、ブラウザに入力するものの始まりのようなものですか?
ライアン:うん。その最初の部分は、使用するプロトコルをブラウザに伝えます。そこに入力するものは、コンピューティングの歴史の中で最も重要なブレークスルーの1つです。
妻:なんで?
ライアン:世界のどこからでも、世界のどこかで何かの場所を記述することができるからです。それがウェブの基礎です。あなたは知識と情報のためのGPS座標のように考えることができます。
妻: Webページの場合?
ライアン:本当に何でも。あの男、ロイ・フィールディング、彼は私が話していたその研究でそれらのものが何を指しているのかについてたくさん語っています。WebはRESTと呼ばれるアーキテクチャスタイルに基づいて構築されています。RESTは、リソースの定義を提供します。これは、それらが指すものです。
妻: Webページはリソースですか?
ライアン:ちょっと。Webページはリソースの表現です。リソースは単なる概念です。URL-ブラウザに入力するもの...
妻: URLとは何か知っています。
ライアン:ああ、そうだね。それらは、どこかに概念があることをブラウザに伝えます。ブラウザは、コンセプトの特定の表現を要求することができます。具体的には、ブラウザはコンセプトのWebページ表現を要求します。
妻:他にはどんな表現がありますか?
ライアン:実際のところ、表現はあまり使われないこれらのものの1つです。ほとんどの場合、リソースには1つの表現しかありません。しかし、あちこちに新しいフォーマットがたくさん出てくるので、将来は表現がもっと使われることを望んでいます。
妻:何が好き?
ライアン:うーん。まあ、人々がWebサービスを呼び出しているというこの概念があります。それは多くの人にとって多くの異なることを意味しますが、基本的な概念は、マシンが人々と同じようにウェブを使用できるということです。
妻:これは別のロボットのものですか?
ライアン:いや、そうでもない。マシンが机に座ってウェブを閲覧するという意味ではありません。しかし、コンピューターはこれらの同じプロトコルを使用して、互いにメッセージをやり取りできます。私たちはそれを長い間行ってきましたが、今日使用している技術はどれも、世界中のすべてのマシンと会話できるようにする必要があるときにうまく機能しません。
妻:どうして?
ライアン:それらはそのように使用するように設計されていなかったからです。フィールディングと彼の仲間がウェブの構築を始めたとき、世界のどこにいてもどんなマシンとも会話できることが最大の関心事でした。コンピューターを相互に通信させるために職場で使用するほとんどの手法には、これらの要件がありませんでした。マシンの小さなグループと話す必要がありました。
妻:そして今、あなたはすべての機械と話す必要がありますか?
ライアン:はい-その他。他のすべてのマシンにあるすべてのものについて、すべてのマシンと話すことができる必要があります。したがって、あるマシンが別のマシン上にある可能性のあるリソースについて別のマシンに伝える方法が必要です。
妻:何?
ライアン:あなたがあなたの妹と話していて、彼女が掃除人か何かを借りたいとしましょう。しかし、あなたはそれを持っていません-あなたのお母さんはそれを持っています。だから、代わりにあなたのお母さんからそれを取得するようにあなたの妹に伝えます。これは実生活で常に発生し、機械も話し始めるときに常に発生します。
妻:それでは、機械はどのように物事がどこにあるのかを互いに伝えますか?
ライアン:もちろん、URL。マシンが話す必要があるものすべてに対応するURLがあれば、名詞に相当するマシンを作成しました。あなたと私、そして世界の他の国々が、特定の方法で名詞について話すことに同意していることは非常に重要ですよね?
妻:うん。
ライアン:機械には普遍的な名詞がありません。すべてのプログラミング言語、データベース、または他の種類のシステムには、名詞について異なる話し方があります。それがURLがとても重要な理由です。これらのシステムのすべてが、お互いの名詞についてお互いに話しましょう。
妻:しかし、私がウェブページを見ているとき、私はそれをそのように考えません。
ライアン:誰もしません。フィールディングと他の一握りを除きます。だからこそ、マシンはまだ吸わないのです。
妻:動詞、代名詞、形容詞はどうですか?
ライアン:おもしろいのは、それがRESTのもう1つの大きな側面だからです。とにかく、動詞はそうです。
妻:私は冗談を言っていました。
ライアン:それは面白い冗談でしたが、実際には冗談ではありません。動詞は重要です。プログラミングおよびCS理論には、ポリモーフィズムと呼ばれる強力な概念があります。これは、異なる名詞に同じ動詞を適用することができると言うこっけいな方法です。
妻:わかりません。
ライアン:まあ..コーヒーテーブルを見てください。名詞は何ですか?カップ、トレイ、新聞、リモート。さて、これらすべてに対してできることは何ですか?
妻:わかりません...
ライアン:入手できますよね?あなたはそれらを拾うことができます。あなたはそれらを倒すことができます。あなたはそれらを燃やすことができます。同じ動詞をそこに座っているオブジェクトに適用できます。
妻:わかりました...そうですか?
ライアン:それは重要です。私に代わりに「カップを手に入れて」「新聞を手に入れて」「リモコンを手に入れて」と言うことができたらどうでしょうか。代わりに、名詞ごとに異なる動詞を作成する必要がある場合はどうなりますか?「get」という単語を普遍的に使用することはできませんでしたが、代わりに動詞/名詞の組み合わせごとに新しい単語を考え出す必要がありました。
妻:すごい!それは変だ。
ライアン:はい、そうです。私たちの脳は、同じ動詞を多くの異なる名詞に適用できることを知っているほど、何とか賢いです。一部の動詞は他の動詞よりも具体的で、少数の名詞セットにのみ適用されます。例えば、私はカップを運転できず、車を飲むことができません。ただし、GET、PUT、DELETEなど、一部の動詞はほぼ普遍的です。
妻:カップを削除することはできません。
ライアン:まあ、大丈夫ですが、捨てることができます。それはもう一つの冗談でしたね?
妻:うん。
ライアン:とにかく、HTTP(このプロトコルFieldingと彼の友人たちが作成したプロトコル)は、すべて名詞に動詞を適用することに関するものです。たとえば、Webページにアクセスすると、ブラウザは入力したURLでHTTP GETを実行し、Webページが返されます。
Webページには通常、画像がありますよね?これらは別個のリソースです。Webページは画像のURLを指定するだけで、ブラウザはすべてのリソースが取得されてWebページが表示されるまで、さらにHTTP GETを実行します。しかし、ここで重要なことは、非常に異なる種類の名詞を同じように扱うことができるということです。名詞が画像、テキスト、ビデオ、mp3、スライドショーなど何であっても。URLを指定すると、これらすべてを同じ方法で取得できます。
妻: GETは非常に重要な動詞のようです。
ライアン:そうです。特に、ブラウザはほとんどGETを使用するため、Webブラウザを使用している場合。彼らは他の種類のリソースとのやり取りをあまりしません。多くの人々がHTTPが単にGETのためのものであると仮定するようになったため、これは問題です。しかし、HTTPは実際には動詞を名詞に適用するための汎用プロトコルです。
妻:かっこいい。しかし、これがどのように変化するかはまだわかりません。どんな種類の名詞と動詞が欲しいですか?
ライアン:名詞はありますが、正しい形式ではありません。
amazon.comをブラウズして、クリスマスに私を買うものを探しているときを考えてください。各製品が名詞であると想像してください。マシンが理解できる表現で利用できる場合、多くのきちんとしたことができます。
妻:マシンが通常のWebページを理解できないのはなぜですか?
ライアン: Webページは人々が理解できるように設計されているからです。マシンはレイアウトとスタイルを気にしません。マシンには基本的にデータが必要です。理想的には、すべてのURLが人間が読める形式とマシンが読める形式になっています。マシンがリソースを取得すると、マシンが読み取り可能なリソースを要求します。ブラウザが人間のリソースを取得すると、人間が読み取れるリソースを要求します。
妻:それで、人々は彼らのすべてのページのために機械フォーマットを作らなければなりませんか?
ライアン:それが価値があるなら。
見てください、私たちはこれについて多くの抽象化で話してきました。実際の例を見てみましょう。あなたは教師です-学校では、大きなコンピューターシステム、またはおそらく3つまたは4つのコンピューターシステムがあり、生徒を管理することができます。生徒のクラス、成績、緊急連絡先、情報システムがウェブベースである場合、おそらくここに含まれる各名詞のURLがあります:学生、教師、クラス、本、部屋など。今、URLを取得するブラウザはWebページを提供します。各URLに機械で読み取り可能な表現がある場合、その情報はすべて標準的な方法で消費されるため、システムに新しいツールをラッチするのは簡単です。また、各システムが互いに対話しやすくなります。または、個々の学校システムのそれぞれと対話してテストのスコアを収集できる州または国全体のシステムを構築できます。可能性は無限大。
各システムは、単純なHTTP GETを使用して互いに情報を取得します。あるシステムが別のシステムに何かを追加する必要がある場合、HTTP POSTを使用します。システムが別のシステムの何かを更新する場合、HTTP PUTを使用します。把握する必要があるのは、データがどのように見えるかだけです。
妻:これはあなたとすべてのコンピューターの人々が今取り組んでいるものですか?データをどのように表示するかを決定しますか?
ライアン:悲しいことに、いいえ。その代わり、大多数は、このようなことを別の方法で行うための複雑な仕様のレイヤーを書くのに忙しく、それはほとんど役に立たないか雄弁ではありません。名詞は普遍的ではなく、動詞は多態的ではありません。私たちは何十年にもわたる実際の現場での使用と実績のある技術を捨て、過去に失敗した他のシステムによく似たものからやり直しています。HTTPを使用していますが、これはHTTPを使用しているため、ネットワークやセキュリティ担当者とのやり取りが少なくなるためです。私たちは、派手なツールとウィザードのシンプルさを交換しています。
妻:なんで?
ライアン:わかりません。
妻:なんで言ってくれないの?
ライアン:たぶん私はそうします。
数十億から数十億数十億の接続状態を保存することはどのように考えられますか?:)そのため、セッションでは必要な状態のみを保存します。
ところで:HTTPはコネクションレスではありません。
persistent connections
、キープアライブと呼ばれることができます。私はネットワークの専門家ではありませんが、ほとんどの場合、HTTPに実際の接続があります:)
デスクトップ開発者は、リッチなUIエクスペリエンスをより快適に使用できます。Webへの移行は一歩後退したような気分になります。Webの世界では、創造性の自由度が低く、制約を感じることができます。それであなたを失望させないでください!移行を支援することができる多くのことがあります。ここにそれらの短いリストがあります。
幸せなプログラミング!
何百万ものウェブページに何百万もなかった時代があったからです。大学と研究施設だけに数ページある時代があったからです。ブロードバンドがない時代があり、httpはデスクの電話の上に置かれた1200ボーモデムと通信されていました。「リッチWebアプリ」は、彼らの見解では、途方もない量の帯域幅を必要とする時代がありました。また、初期のインターネットは非常に信頼性が低いため、TCP / IPが作成されたことを思い出してください。
HTTP 1.0は1990年代初頭に登場しました。当時のインターネットがどのようだったのか、なぜ彼らがそれを彼らのやり方で設計したのかを考えてください。
それはあらゆる種類の進化した。インターネットは、ウェブブラウザやウェブの前に存在していました。それは、ftp、telnet、gopher、ping、finger、その他のいくつかのビットとボブのバブルポットでした。最初のWebブラウザーであるMosaic(私は昔、1991年だったと思いますが、私は大学にいたと思います)は、ftpとドキュメントビューアーの間の一種のミッシュマッシュとして機能しました。魔法は、新しいドキュメントをftpするリンクをドキュメントに含めることができるという点で発生しました。
これからの20年間で進化したすべてのインタラクティブ機能。それは幸せな進化でもありませんでした。ブラウザ戦争があり、IEとNetscapeは標準の制御のためにそれを隠しました(簡略化のビット;))、そして他のさまざまなサードパーティがリッチコンテンツを可能にするプラグインの導入を開始しました。Javaは魔法の弾丸、そしてもちろんFlashになるでしょう。3Dの世界を約束し、スターウォーズモデルの正確に半ダースの3Dモデルを提供したVRMLプラグインを覚えている人はいますか?
私は最後に向かって少し夢中になりましたが、あなたはアイデアを得る:)
主な理由は、アカデミアがHTTPの目的と考えていたものと、スケーラビリティの理由との組み合わせに関係しています。HTMLは元々、学問の境界を越えて情報や論文を共有するために設計されました。それは純粋に定型化されたテキストでした。最初のブラウザで写真を提供できるようになるまで、人々はそのモデルを超えて考え始めました。
次の考慮事項により、ステートレスの決定が強固になりました。
Webページがより複雑になり、多くのグラフィックスとスタイルシートが含まれるようになったため、HTTPは「キープアライブ」フラグで修正されました。これにより、ソケットが有効になり、クライアントが同じ会話で複数のリソースを要求できるようになります。
インターネットの現在の使用モデルを考慮すると、元の決定は依然として有効です。時々不便かもしれませんが、いくつかの小さな量子化されたサーバーとのやり取りは、アイドル状態のソケットよりも優れています。
双方向ブラウザを意味する場合。
セキュリティ上の理由。
たとえば、SPAM!。
それ以外の場合、インターネットはTCP / IP(2つのプロトコル)とUDPを実行します。
伝送制御プロトコル(TCP)は、インターネットプロトコルスイートのコアプロトコルの1つです。TCPは、スイートの2つの元のコンポーネントの1つであり、インターネットプロトコル(IP)を補完するため、スイート全体は一般にTCP / IPと呼ばれます。TCPは同じネットワーク上の2つのホスト間でデータを直接交換するサービスを提供しますが、IPは1つ以上のネットワークでメッセージのアドレス指定とルーティングを処理します。特に、TCPは、あるコンピューター上のプログラムから別のコンピューター上の別のプログラムへのバイトストリームの信頼性の高い順序付き配信を提供します。TCPは、主要なインターネットアプリケーション、World Wide Web、電子メール、ファイル転送などのアプリケーションが依存するプロトコルです。信頼できるデータストリームサービスを必要としない他のアプリケーション、
インターネットプロトコル(IP)は、Internet Protocol Suiteを使用してインターネットワークを介してデータグラム(パケット)を中継するために使用される主要な通信プロトコルです。ネットワークの境界を越えてパケットをルーティングすることを担当し、インターネットを確立する主要なプロトコルです。IPは、インターネットプロトコルスイートのインターネット層の主要なプロトコルであり、アドレスに基づいてソースホストから宛先ホストにデータグラムを配信するタスクがあります。この目的のために、IPはデータグラムのカプセル化のアドレス指定方法と構造を定義します。歴史的に、IPは、1974年にVint CerfとBob Kahnによって導入されたオリジナルの伝送制御プログラムのコネクションレスデータグラムサービスであり、もう1つはコネクション型伝送制御プロトコル(TCP)です。そのため、インターネットプロトコルスイートはしばしばTCP / IPと呼ばれます。
デスクトップアプリケーションでは、ユーザーは開始と終了が定義された一連のタスクを実行していると想定されます。このようなアプリケーションでは、ユーザーがデータを提供するサーバーにログインし、完了するまでログインしたままにすることは(実際にはそれほどではありませんが)理にかなっています。
Webインタラクションは(通常)同じモデルに従いません。たとえば、eコマースサイトでは、ユーザーはGoogle検索の結果として製品の説明にアクセスし、すぐにそのページを離れて、同じ製品の別のサイトの提供を確認できます。または、チェックアウトプロセスを開始し、製品の価格が高すぎると判断し、途中で放棄する場合があります。「ハイパーテキスト」の基本的な考え方は、ある場所から別の場所にジャンプする能力と期待を意味します。
永続的な接続はリソースを消費します。おそらくネットワークソケット、おそらく解析されたデータベースクエリのプールです。それはすべてアプリケーションに依存します。いつでも消える可能性のあるユーザーを考えると、これらのリソースをコミットしたままにしておくのはあまり意味がありません。
実際には、ユーザーが永続的に接続する必要はありません。Webアプリケーションは、必要なリソース(データベースなど)への接続を維持し、すべてのユーザーリクエスト間でそれらを共有します。Webアプリフレームワークはセッションを提供します。セッションは、さまざまなリクエストのユーザーごとのデータを保存する時間制限のある場所です。(簡単に)できないことは、実行時間の長いクライアント制御のトランザクションを使用することだけですが、接続を維持するアプリであってもそれは悪い考えです。
インターネットは必ずしもステートレスではありません-実際、Java EEを見ると、インターネットにはステートフルEJBとステートレスEJBがあります。
開発者がステートレスアーキテクチャの使用を推奨する主な理由は、スケーラビリティのためです。トラフィックをサポートするためにサーバーを追加および削除したら、すべてのユーザーの状態を維持しようとすることを想像してください。
ステートレスアーキテクチャを開発するのは本当に難しくありません。主なポイントは、できるだけ少ない状態(通常はユーザーID-できればCookie内)を維持し、必要に応じてデータベースを変更することです。