この回答が最初に書かれてから、質問が変更された/明確にされたことに注意してください。質問の最新の反復に対するさらなる応答は、2番目の水平ルールの後です。
HTTPプロトコルのGETやPOSTなどのメソッドの必要性は何ですか？
これらは、ヘッダー形式、ヘッダーと本文の分離方法の規則などの他のいくつかのものとともに、HTTPプロトコルの基礎を形成します。
要求本文と応答本文だけを使用してHTTPプロトコルを実装することはできませんか？
いいえ、作成したものはすべてHTTPプロトコルではないため
たとえば、URLにはリクエストが含まれます。リクエストは、サーバー側のプログラミング言語に応じた関数にマッピングされ、サーブレットと応答してHTMLおよびJavaScriptレスポンスが送信されます。
おめでとうございます、あなたは新しいプロトコルを発明しました！さて、もしあなたがそれを推進し、維持し、開発するなどのために標準化団体を設立したいなら、それはいつかHTTPを追い抜く可能性があります
私はこれがちょっと冗談であることに感謝していますが、インターネット、TCP / IP、またはサーバーとクライアント間で行われる通信について魔法のようなものは何もありません。接続を開き、いくつかの単語を送信して、会話を形成します。要求が理解され、適切な応答が配信される場合、会話は実際に両端で批准された仕様に従う必要があります。これは、世界のどのダイアログとも変わりません。あなたは英語を話し、隣人は中国語を話します。手を振ったり、ポインティングしたり、握りこぶしを振れば、家の前に車を停めたくないというメッセージを伝えることができれば幸いです。
HTTPに準拠したWebサーバーへのソケットを開いて次を送信した場合、インターネットに戻ります。
EHLO
AUTH LOGIN
（SMTP電子メール送信の開始）その後、賢明な回答は得られません。最も完璧なSMTP準拠のクライアントを作成できますが、この会話は共有プロトコルに関するものであるため、Webサーバーはクライアントと通信しません。共有プロトコルも喜びもありません。
これが、HTTPプロトコルを実装せずにHTTPプロトコルを実装できない理由です。あなたが書いたものがプロトコルに準拠していない場合、それは単にプロトコルではありません-それは別のものであり、プロトコルで指定されたとおりに機能しません
あなたの例を少し実行すると、クライアントが接続し、URLのように見えるものを記述するだけです。そして、サーバーはそれを理解し、HTML / JS（Webページ）のように見えるものを送信します。あなたは何を保存しましたか？GETを言わないことについてのいくつかのバイト？これらの厄介なヘッダーを捨てることについてはもう少しです。サーバーもいくらか保存しました-しかし、それがあなたに送ったものを解決できない場合はどうでしょうか？JPEGで終わるURLを要求し、画像を作成するためにいくつかのバイトを送信したが、PNGである場合はどうでしょうか。その時点で不完全なPNG。進行中のバイト数を示すヘッダーがあれば送信するには、受信したバイト数が実際にファイル全体であるかどうかがわかります。サーバーが帯域幅を節約するために応答をgzipで圧縮したが、通知しなかった場合はどうなりますか？あなたはそれが送ったものを解決しようとしてかなりの計算能力を費やすことになります。
一日の終わりには、メタ情報-情報に関する情報が必要です。ヘッダーが必要です。ファイルには名前、拡張子、作成日が必要です。喜ばせたり感謝したりするために、誕生日を迎える人が必要です-世界はプロトコルとコンテキストに関する情報でいっぱいなので、座ってすべてをゼロからやり直す必要はありません。それは少しのストレージスペースがかかりますが、簡単に価値があります
さまざまなHTTPメソッドの実装が本当に必要ですか？
おそらく、指定されたプロトコル全体を実装する必要はありません。これは通常、すべてに当てはまります。英語のすべての単語を知っているわけではありません。私の中国人の隣人もソフトウェア開発者ですが、別の業界にいて、私の業界で使用されている用語のいくつかは英語は言うまでもありません。良いことは、HTTPの実装に関するドキュメントを入手すること、サーバーを作成すること、クライアントを異なるアーキテクチャの異なるプログラミング言語で作成すること、およびプロトコルに準拠しているために動作することの両方があることです。
ユーザーの誰もGETリクエスト以外を発行したり、永続的な接続を使用したり、JSON以外を本文として送信したり、text / plain以外を受け入れる必要があるため、クライアントブラウザーの非常に限られた要求のみを満たす、実際に縮小されたWebサーバーを記述します。しかし、「ソケットを通過するテキスト」をHTTPとする基本的なルールを廃止することをto意的に決めることはできませんでした。リクエストが次のような文字列であるという基本概念を捨てることはできません。
VERB URL VERSION
header: value
maybe_body
また、応答にはバージョン、ステータスコード、および場合によってはヘッダーが含まれます。いずれかを変更すると（HTTPではなくなります）、それは別のものであり、それを理解するように設計されたものでのみ機能します。HTTPはこれらの定義によるものであるため、HTTPを実装する場合は、定義に従う必要があります
更新
あなたの質問は少し進化しました。あなたの質問に対する回答を以下に示します。
HTTPプロトコルにメソッドの概念があるのはなぜですか？
歴史的には、スクリプトが存在しなかったり、ページが動的であり、メモリ内で動的に生成され、代わりにソケットを押し下げられるという概念でさえ、物事が設計と実装においてはるかに柔軟性に欠けることを理解する必要がありますクライアントによって要求され、ソケットを読み取り、プッシュダウンしたディスク上の静的ファイルであるということは、存在しませんでした。そのため、初期のウェブは他のページへのリンクを含む静的ページの概念を中心としていたため、すべてのページはディスク上に存在し、ナビゲーションは主に端末がURLのページのGETリクエストを行っていたため、サーバーはマッピングできますディスク上のファイルのURLを送信します。また、互いにリンクし、他の場所にリンクしているドキュメントのウェブは進化しているはずであるという考えもありました。
これにより、メソッドの履歴コンテキストが得られます-かつてURLは柔軟性のないビットであり、ディスク上のページを単純に参照していたため、ファイルとサーバーに対する意図をクライアントが説明できるため、メソッドは有用でしたメソッドをさまざまな方法で処理します。URLが仮想であるという概念や、ハイパーテキストの本来のビジョン（実際にはテキストのみ）での切り替えやマッピングに使用されるという概念はありませんでした。
私はこの答えが、物事が変化し始めた正確な日付と引用文献を含む歴史的記録の文書になることを意図していません-そのためにはおそらくウィキペディアを読むことができます-しかし、それは時間をかけて欲求を言うだけで十分ですより多くの勢いでウェブを獲得し、サーバーとクライアントの接続の両端で、拡張しているリッチマルチメディアエクスペリエンスを作成する機会を提供します。ブラウザは、コンテンツをフォーマットするための膨大な数のタグをサポートしました。各タグは、必須のメディアリッチ機能と物事をおしゃれに見せるための新しい方法を実装するために競っています。
クライアント側にプラグインが到着し、プラグインとブラウザー拡張機能はすべて、ブラウザーをあらゆるものの非常に強力なパワーハウスにすることを目的としています。サーバーエンドでは、アルゴリズムまたはデータベースデータに基づくコンテンツのアクティブな生成が大きな推進力であり、おそらくディスク上におそらくファイルがほとんどない程度まで発展し続けています-確かに、画像またはスクリプトファイルをファイルとして保持しますWebサーバーとブラウザーにそれを取得させますが、ブラウザーが表示する画像とそれが実行するスクリプトは、ファイルエクスプローラーで開くことができるファイルではなく、必要に応じて行われるコンパイルプロセスの出力である生成されたコンテンツです、ピクセルのビットマップ配列ではなくピクセルを描画する方法を説明するSVG、またはTypeScriptのようなスクリプトのより高いレベルのフォームから発行されたJavaScript
最新のマルチメガバイトページを作成する際に、おそらくその一部のみがディスク上の固定コンテンツになります。データベースデータは、ブラウザが使用するhtmlにフォーマットおよび整形され、URLによって何らかの方法で参照される複数の異なるプログラミングルーチンに応じてサーバーによって実行されます。
私は質問に対するコメントで、まるで完全な円に似ていると言いました。コンピューターに数十万の費用がかかり、部屋がいっぱいになったとき、複数のユーザーがキーボードとマウス、緑色の画面、いくつかのテキストを送信し、いくつかを取得する何百ものダム端末を介して1つの超強力な中央メインフレームを使用できるようにすることが一般的でしたテキスト出力。コンピューティングパワーが増加し、価格が下がるにつれて、人々は初期のメインフレームよりも強力なデスクコンピューターと強力なアプリをローカルで実行できるようになり、メインフレームモデルは時代遅れになりました。しかし、それは決して消えることはありませんでした。なぜなら、物事は進化して逆になり、便利なアプリ機能のほとんどを提供する中央サーバーと、画面に描画する以外はほとんど実行しない100台のクライアントコンピューターにいくらか戻って サーバーとの間でデータを送受信します。あなたのコンピューターが単語と見通しのコピーを同時に実行できるほどスマートだったその中間期間は、再びオフィスのオンラインに道を譲りました。そこでは、ブラウザーは画面に絵を描き、文書/メールを編集するためのデバイスです。サーバー上に存在するものとして書き直し、そこに保存され、送信され、他のユーザーと共有されます。これは、ブラウザーが、他の場所に存在するこのもののある部分を部分的に表示する単なるシェルであるという概念です
答えから、メソッドの概念が存在する理由をある程度理解できます。これは別の関連する質問につながります。
たとえば、Gmail作成リンクでは、PUT / POSTリクエストとデータが送信されます。ブラウザはどの方法を使用するかをどのようにして知るようになりますか？
デフォルトではGETを使用します。規則/仕様により、URLを入力してreturnキーを押すとそれが決定されるため、
サーバーから送信されたGmailページには、Gmail作成要求を呼び出すときに使用するメソッド名が含まれていますか？
これは、上記のコメントで言及した重要なことの1つです。最新のウェブでは、ページについてでさえありません。ページがディスク上のファイルである場合、ブラウザはGETします。その後、データをテンプレートにスロットすることにより、主に動的に生成されるページになりました。しかし、それでも「サーバーからの新しいページのリクエスト、ページの取得、ページの表示」プロセスが含まれていました。ページスワッピングは非常に滑らかになりました。レイアウトの読み込みやサイズ変更、ジャークが表示されなかったため、スムーズになりましたが、それでもブラウザがページ全体またはページの一部を別のものに置き換えていました。
物事を行う最新の方法は、単一ページのアプリケーションを使用することです。ブラウザーはメモリ内に特定の方法で表示されるドキュメントを持ち、bservrの呼び出しをスクリプティングして情報のナゲットを取得し、ドキュメントを操作してページの一部が新しい情報を表示するように視覚的に変更します。ブラウザが別の新しいページをロードする; それは、UIになり、その一部が、言葉や見通しのような典型的なクライアントアプリのように更新されます。新しい要素は他の要素の上に表示され、ダイアログウィンドウなどをシミュレートしてドラッグできます。これはすべて、開発者が望むhttpメソッドを使用してリクエストを送信し、ブラウザが描画しているドキュメントを取得してデータを取得するブラウザスクリプトエンジンです。最新のブラウザーは、オペレーティングシステム全体または仮想コンピューターのような優れたデバイスであると考えることができます。画面上での描画、サウンドの再生、ユーザー入力のキャプチャ、処理のための送信をかなり標準化した方法を備えたプログラマブルデバイス UIを描画するために必要なことは、UIを作成するhtml / cssを提供してから、常にHTMLを微調整して、ブラウザが描画するものを変更することだけです。ええと、人々はアドレスバーの変更を見る/それを意図の方向として使用することに慣れているので、ナビゲーション（新しいページ全体を要求する）が行われていなくても、単一のページアプリがURLをプログラムで変更します UIを描画するために必要なことは、UIを作成するhtml / cssを提供してから、常にHTMLを微調整して、ブラウザが描画するものを変更することだけです。ええと、人々はアドレスバーの変更を見る/それを意図の方向として使用することに慣れているので、ナビゲーション（新しいページ全体を要求する）が行われていなくても、単一のページアプリがURLをプログラムで変更します UIを描画するために必要なことは、UIを作成するhtml / cssを提供してから、常にHTMLを微調整して、ブラウザが描画するものを変更することだけです。ええと、人々はアドレスバーの変更を見る/それを意図の方向として使用することに慣れているので、ナビゲーション（新しいページ全体を要求する）が行われていなくても、単一のページアプリがURLをプログラムで変更します
www.gmail.comを呼び出すとき、GETメソッドを使用している必要がありますが、ブラウザはこのメソッドを使用することをどのように認識していますか？
本当です。指定されているため。最初のリクエストは、これまで常にそうであったように、最初のhtmlを取得してUIを描画し、それを永久に突いて操作するか、他のスクリプトで別のページを取得して、反応して反応するUIを突いて操作します
いくつかの答えが示すように、DELETEメソッドで新しいユーザーを作成できます。これにより、HTTPプロトコルのメソッドの概念の背後にある意図を疑問視します。クライアントがURLに使用する方法をサーバーに伝える必要があるのはなぜですか。
歴史。レガシー。理論的には明日、すべてのhttpメソッドを投げ捨てることができます。URLはデータを保存するサーバーに示す切り替えメカニズムになりうるため、URLは処理可能であるため、メソッドは廃止されます。ドラフトメールとしての本文、またはドラフトの削除-サーバーに/ emails / draft / save / 1234ファイルがありません-サーバーは、そのURLを選択して本文データの処理方法を知るようにプログラムされていますID 1234の下にあるドラフトメールとして
そのため、メソッドを廃止することは確かに可能ですが、メソッドを中心に成長したレガシー互換性の大きな重みを除きます。必要なものだけにそれらを使用する方が良いですが、大部分は無視して、代わりにあなたの物を動作させるために必要なものを使用します。メソッドが必要なのは、アプリが作成されたブラウザおよびサーバーにとって何か意味があることを覚えておく必要があるためです。クライアント側のスクリプトは、基礎となるブラウザを使用してデータを送信する必要があり、ブラウザが要求どおりに実行するメソッドを使用する必要があります-おそらくPOSTは可変情報をすべてURLにパックし、長さに制限があるためです多くのサーバーで。クライアントはサーバーからの長い応答を望んでいます-応答ボディを持つことはまったく想定されていないため、HEADは使用しないでください。