HTTPの状態の欠如は、プロトコルを最新のアプリケーションに適合させませんか？[閉まっている]

PHPからASP.NETに変更しましたが、今はやや大規模な会社でWebフォームを使用しています。しかし、ASP.NET Webフォームに関する印象を裏付けるためにいくつか調査を行い、Webフォームは「デスクトッププログラミング」の世界から来た人のためにWebアプリケーションを簡単に作成できるようにするための試みであるという結論に達しました。

しかし、私はWebフォームを回避する前に、私たちが作成したソフトウェアのニーズを分析することを決定し、Web上のアプリケーションの状態を維持する問題にぶつかりました。

HTTPはステートレスプロトコルであり、ASP.NETはセッション変数、hiddenfields、viewstatesを使用して状態をシミュレートしようとしていることを理解しています。上記のすべてに欠陥があり、状態を維持するのに完全ではないことも理解していますアプリケーションですが、アプリの状態を維持する必要性も理解しています。

どちらが問題を提起しますか、HTTPはこのタイプのジョブ（状態を必要とするアプリケーションの作成）に本当に適していますか？現在、ツールはWeb開発者が利用できますか？HTML5で利用できる新しいツールは仕事で効果的ですか、それともHTTPの制限に対する回避策にすぎませんか。

私はWeb用に開発するのが大好きで、デスクトップよりもWebに精通しています。このHTTPのステートレス性についてしばらく疑問に思っていたので、ポイントが足りないのか、それともm私の考えにぴったりです。

プロトコルはステートレスかもしれませんが、あなたが書くアプリはどんな状態も維持できます:)

HTTPは確かに古いテクノロジーであり、Webが普及するにつれ、かなり普及してきました。その結果、人々はこのテクノロジーを拡張して、HTTPのステートレス性が問題であると思われる現代のWebアプリで現在多くのことを行うようになっています。したがって、ビューステートなどの便利な機能がたくさんあります。

ただし、ステートレスな方法で最新のWebアプリをコーディングすることもできます。これは多くの場合推奨されます。RESTfulWeb開発はこのアイデアに基づいています。最新のWebアプリの基礎を形成する多くのWeb APIは、本当にステートレスであり、そうでなければなりません。これは、考えて設計する別の方法です。あなたのニーズは、あなたが何をしているかによって異なります。

生のプロトコルレイヤーに到達すると、多くのプロトコルはステートレスです。ステートフル性はWeb開発の主要な障害ではありません。主な障害は、デフォルトではHTTPがセッションレスであることです。つまり、デフォルトでは、ブラウザからサーバーへの一連のリクエストは互いに無関係です。

これを回避するには、Cookieを使用してセッションを示します。ASP.NETサーバーはCookieをブラウザーに提供し、ブラウザーは後続の要求でそれを返します。ASP.NETは舞台裏でそのCookieを探し、キャッシュしているセッションに接続します（セッションがタイムアウトしていない場合）。

そこから、他のデータをセッションに関連付けて、ユーザーごとにカスタマイズされたエクスペリエンスを作成するために使用できます。Webサーバーとフレームワークはこの点で非常に優れており、HTTPプロトコルの上にリッチクライアントを構築できます。適例として、Twitterクライアントは、友人やツイートのリストの取得から他のユーザーへの直接メッセージの送信まで、すべてにhttpを使用します。（私は多少簡略化しています。完全に接続されたTCPストリーミングプロトコルがtwitterを通じて利用可能ですが、ほとんどの場合、HTTPがすべての中核です。

HTMLは適切な表示技術としてある程度限界に達していますが、HTML 5標準とJavaScriptおよびCSS 3により、ネイティブクライアントで可能であることに匹敵するリッチなUIを作成できるようになりました。実際、HTML 5はこれまでに登場しており、Windows 8アプリのネイティブテクノロジーとしてサポートされています。クライアントのJQueryやサーバーのNodeJSなどのライブラリを使用すると、クライアントとサーバーのロジックにJavaScriptを、ディスプレイにHTMLを、通信に純粋なHTTPを使用するアプリケーションを作成できます。

したがって、HTML / HTTPが限界に達したという過去の議論にはある程度のメリットがあったかもしれませんが、もはやそうではありません。