ステートレスインターネットの理解[終了]


15

私はデスクトップ開発者からWeb開発者に移行していますが、HTTPがステートレスである理由を理解するのに苦労しています。その理由は何ですか?私のようなデスクトップ開発者がステートレス開発環境に移行する方法は何ですか?


3
こんにちは、ブライアン、Programmers.SEはディスカッション掲示板ではありません。あなたが助けを必要としているあなたが直面している特定の問題はありますか?もしそうなら、質問を言い換えることはできますか?

通常は、サーバーにセッションCookieの詳細を処理させます。
FrustratedWithFormsDesigner

十数個の「適切な回答」が得られたので、これは再開すべきだと思います。特に、この問題を再現すると言われている別の最近の質問によって指摘されたからです。そもそもここにあることになっていない場合、どちらの方向にも重複することはできません。ここでいくつかの正気を持ちましょう。

回答:


18

これは私が見たステートレスインターネットの最良の説明です:

 妻に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を使用しているため、ネットワークやセキュリティ担当者とのやり取りが少なくなるためです。私たちは、派手なツールとウィザードのシンプルさを交換しています。

妻:なんで?

ライアン:わかりません。

妻:なんで言ってくれないの?

ライアン:たぶん私はそうします。


1
それは素晴らしい読み物です。そのため、httpは慣例で使用されているため、簡単です。私が追加する唯一のものは、Slawekが指摘したように、メモリの制約に関するものです。大規模なWebサイトのリソースはすぐに使い果たしてしまいます。ある日、マシンのリソースがユーザーのニーズに比べて大きい場合、ステートフルインターネットを使用できます。
P.Brian.Mackey

5
私は無国籍であることを恐れることはありません。それは物事を見るだけの別の方法です。時間が経つにつれて、特に大規模でスケーラブルなアプリケーションの場合、実際にはより賢明な方法であることがわかるかもしれません。とにかく、いつでもデータベースに状態を保存し、後続のページ要求でその状態を取得できます。ステートレスは、少しの状態の更新ではなく、トランザクションの観点でより多くのことを考えさせます。
ロバートハーベイ

2
プログラミングに対するステートフルなアプローチに非常に盲目だったため、記事の根本的なポイントを見逃しました。「ステートレスは欠陥ではない」というモットーを数百回脳に打ち込む必要があります。すばらしいコメントと回答をありがとう。
P.Brian.Mackey

最後の段落(末尾から5行)への参照は何ですか?私はアイデアを持っていましたが、私は馬鹿のように推測をしたくはありませんでした。
スティーブン

1
@Steven:その段落はSOAPのようなもの、あるいはCORBA(震え)のことを指していると思います。
ロバートハーヴェイ

6

数十億から数十億数十億の接続状態を保存することはどのように考えられますか?:)そのため、セッションでは必要な状態のみを保存します。

ところで:HTTPはコネクションレスではありません。


1
@P。:とあなたが引用してきたリファレンスが開いたとき、それはほとんど心強いんだこの記事はイタチの言葉、しばしば偏っ伴うあいまいな言い回しや検証できない情報が含まれています。
chrisaycock

3
HTTPはコネクションレスです。HTTPに関する限り、接続が終了すると、HTTPリクエストを送信し、何かを取得します。サーバーが異なるリクエストを接続してセッションを形成することは可能ですが、それはHTTP固有のプロパティではありません。
デビッドソーンリー

2
HTTPは(UDPではなく)TCP / IPをトランスポートとして使用していますが、これは別のISO OSIレイヤーでありpersistent connections、キープアライブと呼ばれることができます。私はネットワークの専門家ではありませんが、ほとんどの場合、HTTPに実際の接続があります:)
Slawek

2
わかりました、それで私がこれから得ていることは、コネクションレスはステートレスと同一視できるという一般的な信念は間違っているということです。httpはステートレスであることに同意するか、仕様を見てw3.org/TR/html401/interact/forms.html(ステートレス検索)を確認することができると思います。http ietf.org/rfc/rfc2616.txtのステートレス性については、RFC2616も参照してください。接続はありますが、接続は「ブラインドリレー」です。
P.Brian.Mackey

2
接続はWeb上で仮想です。技術的に言えば、真の接続を得るには、電話線のように反対側に接続する専用のワイヤが必要です(少なくとも<90年代)。一方が「切断」した場合、もう一方がもうリッスンしていないというパケットを受信しない限り、他方は知りません。理論的には、そのパケットは決して到着しないかもしれません。タイムアウト後、サーバーも「切断」します。ただし、このため、接続は常に仮想です。
ニール

4

デスクトップ開発者は、リッチなUIエクスペリエンスをより快適に使用できます。Webへの移行は一歩後退したような気分になります。Webの世界では、創造性の自由度が低く、制約を感じることができます。それであなたを失望させないでください!移行を支援することができる多くのことがあります。ここにそれらの短いリストがあります。

  1. 状態は共有できますが、サーバーで頻繁に保持され、セッションID、URLパラメーター、隠しフィールド、Cookie値などのトークンを使用して参照されます。
  2. ステートレスモデルは、トランザクション処理に適しています。必要な状態の量を減らすことができるような方法でモデルを構築してみてください。トランザクション処理のACID原則は、これを実現するのに役立ちます。
  3. MVCパターンに精通します(まだ習得していない場合)。これは、懸念事項の分離を維持することにより、設計の改善に役立ちます。Struts(Java)やMVC(.NET)などの一般的なフレームワークは、この概念に基づいて構築されています。
  4. 超リッチなUIエクスペリエンスを実現するには、JavaFlashSilverlightなどのプラグインの使用を検討してください。セミリッチエクスペリエンスの場合は、JQueryAJAXなどの一般的なJavaスクリプトベースのライブラリの使用を検討してください。

幸せなプログラミング!


1
ちょっとした注意:MVCの頭字語に注意してください。もともとはGUIアプリのオブジェクト指向設計として定義されていましたが、後にWebアプリのレイヤーアーキテクチャに組み込まれました。これらは非常に異なるものです。
ハビエル

最初に基本を学ぶのではなく、ステートレスのWeb上の回避策を提供するテクノロジーに直接飛び込むようにOPを提案していますか?
Tulainsコルドバ

3

何百万ものウェブページに何百万もなかった時代があったからです。大学と研究施設だけに数ページある時代があったからです。ブロードバンドがない時代があり、httpはデスクの電話の上に置かれた1200ボーモデムと通信されていました。「リッチWebアプリ」は、彼らの見解では、途方もない量の帯域幅を必要とする時代がありました。また、初期のインターネットは非常に信頼性が低いため、TCP / IPが作成されたことを思い出してください。

HTTP 1.0は1990年代初頭に登場しました。当時のインターネットがどのようだったのか、なぜ彼らがそれを彼らのやり方で設計したのかを考えてください。


「後期」インターネットはまだ信頼できません。
ペムダス

@Pemdas-「後期」インターネットとはどういう意味ですか?
P.Brian.Mackey

ちょうどピッキング。TCPのようなプロトコルがないと、データ送信は依然として信頼できず、TCPでさえも利用できない接続を説明できません。
ペムダス

3

それはあらゆる種類の進化した。インターネットは、ウェブブラウザやウェブの前に存在していました。それは、ftp、telnet、gopher、ping、finger、その他のいくつかのビットとボブのバブルポットでした。最初のWebブラウザーであるMosaic(私は昔、1991年だったと思いますが、私は大学にいたと思います)は、ftpとドキュメントビューアーの間の一種のミッシュマッシュとして機能しました。魔法は、新しいドキュメントをftpするリンクをドキュメントに含めることができるという点で発生しました。

これからの20年間で進化したすべてのインタラクティブ機能。それは幸せな進化でもありませんでした。ブラウザ戦争があり、IEとNetscapeは標準の制御のためにそれを隠しました(簡略化のビット;))、そして他のさまざまなサードパーティがリッチコンテンツを可能にするプラグインの導入を開始しました。Javaは魔法の弾丸、そしてもちろんFlashになるでしょう。3Dの世界を約束し、スターウォーズモデルの正確に半ダースの3Dモデルを提供したVRMLプラグインを覚えている人はいますか?

私は最後に向かって少し夢中になりましたが、あなたはアイデアを得る:)


大丈夫、他の多くの人々、主にマーケティングの人々も夢中になりました。生の利益の動機を除いて、私たちは今どこにいるでしょうか?まだいくつかのオタクが「いくつかのコンピューターを接続している」と思います。

3

主な理由は、アカデミアがHTTPの目的と考えていたものと、スケーラビリティの理由との組み合わせに関係しています。HTMLは元々、学問の境界を越えて情報や論文を共有するために設計されました。それは純粋に定型化されたテキストでした。最初のブラウザで写真を提供できるようになるまで、人々はそのモデルを超えて考え始めました。

次の考慮事項により、ステートレスの決定が強固になりました。

  • 典型的なやり取りは、簡単なダウンロードと読書でした。次の要求までの遅延の間、ソケットはアイドル状態になります。
  • ソケットは貴重なシステムリソースを占有します。SMTPのように会話を維持する必要がなかった場合、1台のマシンで何千ものクライアントを処理するために多くのことができます。
  • 彼らはすでに、リモートシェルアカウント、NFS、SMTP、およびその他のステートフル接続プロトコルの管理から貴重な教訓を学びました。

Webページがより複雑になり、多くのグラフィックスとスタイルシートが含まれるようになったため、HTTPは「キープアライブ」フラグで修正されました。これにより、ソケットが有効になり、クライアントが同じ会話で複数のリソースを要求できるようになります。

インターネットの現在の使用モデルを考慮すると、元の決定は依然として有効です。時々不便かもしれませんが、いくつかの小さな量子化されたサーバーとのやり取りは、アイドル状態のソケットよりも優れています。


3

双方向ブラウザを意味する場合。

セキュリティ上の理由。

たとえば、SPAM!。

Webでの双方向通信を次のレベルに

それ以外の場合、インターネットは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と呼ばれます。


3

デスクトップアプリケーションでは、ユーザーは開始と終了が定義された一連のタスクを実行していると想定されます。このようなアプリケーションでは、ユーザーがデータを提供するサーバーにログインし、完了するまでログインしたままにすることは(実際にはそれほどではありませんが)理にかなっています。

Webインタラクションは(通常)同じモデルに従いません。たとえば、eコマースサイトでは、ユーザーはGoogle検索の結果として製品の説明にアクセスし、すぐにそのページを離れて、同じ製品の別のサイトの提供を確認できます。または、チェックアウトプロセスを開始し、製品の価格が高すぎると判断し、途中で放棄する場合があります。「ハイパーテキスト」の基本的な考え方は、ある場所から別の場所にジャンプする能力と期待を意味します。

永続的な接続はリソースを消費します。おそらくネットワークソケット、おそらく解析されたデータベースクエリのプールです。それはすべてアプリケーションに依存します。いつでも消える可能性のあるユーザーを考えると、これらのリソースをコミットしたままにしておくのはあまり意味がありません。

実際には、ユーザーが永続的に接続する必要はありません。Webアプリケーションは、必要なリソース(データベースなど)への接続を維持し、すべてのユーザーリクエスト間でそれらを共有します。Webアプリフレームワークはセッションを提供します。セッションは、さまざまなリクエストのユーザーごとのデータを保存する時間制限のある場所です。(簡単に)できないことは、実行時間の長いクライアント制御のトランザクションを使用することだけですが、接続を維持するアプリであってもそれは悪い考えです。


2

インターネットは必ずしもステートレスではありません-実際、Java EEを見ると、インターネットにはステートフルEJBとステートレスEJBがあります。

開発者がステートレスアーキテクチャの使用を推奨する主な理由は、スケーラビリティのためです。トラフィックをサポートするためにサーバーを追加および削除したら、すべてのユーザーの状態を維持しようとすることを想像してください。

ステートレスアーキテクチャを開発するのは本当に難しくありません。主なポイントは、できるだけ少ない状態(通常はユーザーID-できればCookie内)を維持し、必要に応じてデータベースを変更することです。


1

私はそれがそのように始まり、ちょうどそのようであり続けたと思います。現在、非常に多くのインフラストラクチャが構築されているため、変更することはできません。

おそらく、最初は接続の信頼性が低く、帯域幅も小さかったため、ステートレスで起動した可能性があります。アクティブな接続があまりない場合は、より多くのトラフィックをより簡単に処理できます。

より良い情報がある場合は、編集するかコメントを残してください。または、自分の答えを投稿してください。


1

その理由は、サーバーサービスを提供するためです(名前に含まれています)。あなたはリクエストをして答えを受け取ります-それだけです。

Web開発への移行に関しては、ASP.NET Web Formsがより理解しやすい方法でそれを行うと信じています。


私はかつてASP.NET Webフォームへの移行を試みたWinforms開発者でした。経験は快適ではありませんでした。ASP.NET MVCの方が好きです。
ロバートハーベイ

ああ、そうですね-私はPHPで始めてから引っ越しました。ループ内でHTMLの生成を停止するのに約6か月かかりました
1

1

HTTP(HyperText Transfer Protocol)の名前を分析することで、多くのことが理解できます。リッチなUIプロトコルとして設計されたことはありません。元々のアイデアは、ドキュメントをリンクで共有することでした。書類をお願いします。その書類のコピーを返信してください。

元々HTTPにはGET動詞が1つしかありませんでした。その点で、静的コンテンツ用に設計されました。誰かが共有しているドキュメントをリクエストするだけで、状態が必要なのはなぜですか?そして、それがHTTPがステートレスである理由です...その起源のために。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.