HTTPプロトコルのGETやPOSTなどのメソッドの必要性は何ですか？
リクエストボディとレスポンスボディのみを使用してHTTPプロトコルを実装することはできませんか？
たとえば、URLにはリクエストが含まれます。これはサーバー側のプログラミング言語に応じて関数にマッピングされ、サーブレットと呼ばれ、それに応答してHTMLおよびJavaScript応答が送信されます。
HTTPプロトコルにメソッドの概念があるのはなぜですか？
答えから、メソッドの概念が存在する理由がわかります。これは、別の関連する質問につながります。
たとえば、gmailの作成リンクでは、PUT/POSTリクエストとデータが送信されます。ブラウザーはどの方法を使用するかをどのようにして知るのですか？サーバーから送信されたGmailページには、Gmail作成リクエストを呼び出すときに使用するメソッド名が含まれていますか？ www.gmail.comを呼び出す場合、GETメソッドを使用している必要がありますが、ブラウザはこのメソッドを使用することをどのように認識しますか？
[〜＃〜] ps [〜＃〜]：回答にコメントするための十分なクレジットがないため、関係者から寄せられた多くの質問にコメントすることができませんこの質問の背後にある意図。
いくつかの回答が示すように、DELETEメソッドで新しいユーザーを作成できます。これにより、httpプロトコルのメソッドの概念の背後にある意図に疑問が生じます。結局のところ、URLをマッピングする機能をサーバーに完全に依存しているためです。 。クライアントがURLに使用するメソッドをサーバーに指示する理由.
注意してくださいこの回答が最初に書かれてから質問が変更/明確化されました。質問の最新の反復に対する追加の応答は、2番目の水平ルールの後です
GETやPOST HTTPプロトコルのようなメソッドの必要性は何ですか？
それらは、ヘッダー形式のようないくつかの他のものとともに、ヘッダーと本文がどのように分離されるかの規則が、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圧縮したが通知しなかった場合はどうなりますか？かなりの計算能力を費やして、送信されたものを計算することになります。
結局のところ、私たちはneedメタ情報-情報に関する情報です。ヘッダーが必要です。名前、拡張子、作成日を含むファイルが必要です。私たちは人々に誕生日、感謝や感謝などを伝える必要があります-世界にはプロトコルとコンテキストに関する情報がたくさんあるので、いつも座ってすべてを最初からやり直す必要はありません。少しのストレージスペースが必要ですが、簡単に価値があります
さまざまなHTTPメソッドの実装が本当に必要ですか？
おそらく、指定されたプロトコル全体を実装する必要はありません。これは通常、何にでも当てはまります。英語の単語をすべて知っているわけではありません。私の中国人の隣人はソフトウェア開発者でもありますが、別の業界にいて、英語はもちろん、私の業界で使用されているいくつかの用語について中国人さえ知りません。良いことですが、HTTPの実装に関するドキュメントを両方とも手に入れることができます。彼はサーバーを記述でき、私はさまざまなアーキテクチャのさまざまなプログラミング言語でクライアントを記述できます。プロトコルに準拠しているため、引き続き機能します。
ユーザーがGETリクエスト以外を発行したり、永続的な接続を使用したり、JSON以外を本文として送信したり、text/plain以外のものを受け入れたりする必要がない場合は、クライアントブラウザーのごく限られた要求にのみ応える、本当に縮小されたWebサーバーを記述します。しかし、「ソケットを通過する一部のテキスト」をHTTPとする基本ルールを廃止することを勝手に決めることはできません。リクエストが次のような文字列になるという基本的な概念を捨てることはできません。
VERB URL VERSION
header: value
maybe_body
そして、応答にはバージョン、ステータスコード、そしておそらくヘッダーが含まれます。それを変更した場合-それはもはやHTTPではありません-それは何か別のものであり、それを理解するように設計されたものでのみ機能します。 HTTPは、これらの定義によるものです。したがって、HTTPを実装する場合は、定義に従う必要があります。
更新
あなたの質問は少し進化しました、あなたが尋ねたことに対するいくつかの応答はここにあります：
HTTPプロトコルにメソッドの概念があるのはなぜですか？
歴史的には、スクリプトが存在せず、ページが動的であり、メモリ内で即座に生成され、代わりにソケットを押し下げることができるという概念さえも、設計と実装においてはるかに柔軟性がないことを理解する必要がありますクライアントによって要求され、ソケットを読み取ってプッシュダウンしたディスク上の静的ファイルであることは存在しませんでした。そのため、非常に初期のWebは、他のページへのリンクを含む静的ページの概念を中心としていたため、すべてのページがディスク上に存在し、ナビゲーションは、ほとんどの場合、URLのページに対してGET要求を行う端末によって行われ、サーバーはマップできました。ディスク上のファイルへのURLを指定して送信します。また、相互にリンクし、他の場所にリンクしているドキュメントのWebは進化する進化可能なものである必要があるため、適切な資格を持つ許可されたユーザーが必ずしもWebを更新できないように、一連のメソッドが存在することが理にかなっているという考えもありました。サーバーファイルシステムへのアクセス権-PUTやDELETEなどのユースケース、およびHEADのような他のメソッドは、クライアントがドキュメントを取得するかどうかを決定できるようにドキュメントに関するメタ情報のみを返しました再び（私たちはダイヤルアップモデムの時代について話していることを思い出してください。本当に原始的な遅い技術です。ハーフメガバイトのファイルのメタを取得し、変更されていないことを確認して、キャッシュからローカルコピーをサーバーに保存することは、かなりの節約になります。もう一度ダウンロードするより
これにより、メソッドにいくつかの歴史的なコンテキストが与えられます-かつてURLは柔軟性のないビットであり、単純にディスク上のページを参照していたため、クライアントがファイルとサーバーの意図を説明できるため、メソッドは有用でしたさまざまな方法でメソッドを処理します。ハイパーテキスト（および実際にはテキストのみ）の元のビジョンでは、URLが仮想である、または切り替えやマッピングに使用されるという概念は実際にはありませんでした
私はこの答えが日付の歴史的記録の文書であり、物事がいつ変化し始めたかの正確な参照を引用するつもりはありません-そのため、おそらくウィキペディアを読むことができます-しかし、長い間、ウェブがさらに勢いを増し、サーバーとクライアントの接続の両端で、拡張しているリッチなマルチメディアエクスペリエンスを作成する機会が得られます。ブラウザは、コンテンツをフォーマットするためのタグの巨大な急増をサポートしました。
スクリプトは、クライアントエンド、プラグイン、ブラウザ拡張機能に到着しました。これらはすべて、ブラウザをあらゆる能力を備えた非常に強力なものにすることを目的としています。サーバーエンドでは、アルゴリズムやデータベースデータに基づくコンテンツのアクティブな生成が大きな推進力であり、ディスク上におそらくファイルがほとんどない程度に発展し続けています-確かに、画像またはスクリプトファイルをファイルとして保持していますWebサーバーとブラウザーにそれを取得させますが、ブラウザーが表示する画像とそれが実行するスクリプトは、ファイルエクスプローラーで開くことができるファイルではなく、オンデマンドで行われるコンパイルプロセスの出力である生成されたコンテンツです、ピクセルのビットマップ配列ではなくピクセルを描画する方法を記述したSVG、またはTypeScriptのようなスクリプトのより高いレベルのフォームから出力されたJavaScript
現代の数メガバイトのページを作成する際、おそらくその一部のみがディスク上の固定コンテンツになっています。データベースデータは、ブラウザーが消費するhtmlにフォーマットおよび整形され、URLによって何らかの方法で参照される複数の異なるプログラミングルーチンに応答してサーバーによって実行されます。
質問へのコメントで、まるでまるまるのようなものだと述べました。コンピューターのコストが数十万で部屋がいっぱいになったとき、複数のユーザーが数百のダム端末（キーボードとマウス、緑色の画面、いくつかのテキストを送信、いくつかを取得）を介して1つの超強力な中央メインフレームを使用できるようにするのが一般的でしたテキストアウト。コンピューティング能力が向上し価格が下がるにつれて、人々は結局、初期のメインフレームよりも強力なデスクコンピュータと、強力なアプリをローカルで実行できるようになり、メインフレームモデルが古くなりました。しかし、それは決して消えることはありませんでした。物事は進化して、他の方向にシフトし、中央のサーバーに戻って、便利なアプリ機能のほとんどを提供し、画面に描画する以外はほとんど機能せず、データの送信と受信を行う100台のクライアントコンピューターに戻ったからです。 /サーバーから。コンピュータがWordとOutlookのコピーを同時に実行できるほどスマートだったその中間期が、オンラインのオフィスに再び移行しました。ブラウザは、画面上に画像を描画し、ドキュメント/メールを編集するためのデバイスです。サーバー上にあるものとして書き直し、そこに保存し、他のユーザーと共有するすべてのことは、ブラウザーが他の場所にあるもののいつでも部分的なビューを提供する単なるシェルであるという概念として
答えから、メソッドの概念が存在する理由がわかります。これは、別の関連する質問につながります。
たとえば、gmailの作成リンクでは、PUT/POSTリクエストとデータが送信されます。ブラウザーはどの方法を使用するかをどのようにして知るのですか？
URLを入力してReturnキーを押すと、規定されていることになるため、規約/仕様により、デフォルトでGETが使用されます。
サーバーから送信されたGmailページには、Gmail作成リクエストを呼び出すときに使用するメソッド名が含まれていますか？
これは、上記のコメントで触れている重要な点の1つです。現代のウェブでは、もはやページについてさえそうではありません。ページがディスク上のファイルになると、ブラウザはそれを取得します。その後、それらは、データをテンプレートに組み込むことによって主に動的に生成されるページになりました。しかし、それでも「サーバーからの新しいページのリクエスト、ページの取得、ページの表示」プロセスが必要でした。ページスワッピングは本当に滑らかになりました。あなたはそれらがロードされ、サイズ変更され、レイアウトがぐちゃぐちゃになったのでそれがよりスムーズに見えるのを見なかったが、それでもブラウザはページ全体またはページの一部を別のものに置き換えていた
物事を行う最新の方法は、単一ページのアプリケーションを使用することです。ブラウザーには、特定の方法で表示されるメモリ内のドキュメントがあり、サーバーへのスクリプト呼び出しと情報のナゲットを取得し、ページの一部が新しい情報を表示するように視覚的に変化するようにドキュメントを操作します-すべてが実行されますブラウザーが別の新しいページをロードしない場合。 WordやOutlookなどの一般的なクライアントアプリのように、一部が更新されるUIになります。新しい要素は他の要素の上に表示され、ダイアログウィンドウなどのシミュレーションの周りにドラッグできます。これはすべて、開発者が望む任意のhttpメソッドを使用してリクエストを送信し、データを取得して、ブラウザーが描画しているドキュメントを突っ込むブラウザースクリプトエンジンです。最近のブラウザーは、オペレーティングシステム全体や仮想コンピューターのような素晴らしいデバイスであると考えることができます。画面上に描画する、サウンドを再生する、ユーザー入力をキャプチャして処理するために送信する、かなり標準化された方法を持つプログラム可能なデバイス。 UIを描画するために必要なのは、UIを作成するいくつかのhtml/cssを提供することだけです。その後、常にhtmlを微調整して、ブラウザーに描画内容を変更させます。一体、人々はアドレスバーの変化を見るのに慣れている/ナビゲーション（まったく新しいページを要求する）が行われていなくても、単一ページのアプリがプログラムでURLを変更するという意図としてそれを使用している
www.gmail.comを呼び出す場合、GETメソッドを使用している必要がありますが、ブラウザはこのメソッドを使用することをどのように認識しますか？
確かにGETです。指定されているため。最初のリクエストは、歴史的に常にUIを描画するために最初のhtmlを取得し、それを永遠にポークして操作するか、または他のスクリプトを使用して別のページを取得し、ポークして操作して応答性の高いリアクティブUIを作成します。
いくつかの回答が示すように、DELETEメソッドで新しいユーザーを作成できます。これにより、httpプロトコルのメソッドの概念の背後にある意図に疑問が生じます。結局のところ、URLをマッピングする機能をサーバーに完全に依存しているためです。 。クライアントがURLに使用するメソッドをサーバーに指示する理由.
歴史。レガシー。理論的には明日すべてのhttpメソッドを破棄することができます。URLは、データを保存することをサーバーに通知する切り替えメカニズムになる可能性があるため処理可能であるため、メソッドは廃止されている高度なプログラミングレベルにあります。本文を下書きメールとして削除するか、下書きを削除します-サーバーに/ emails/draft/save/1234ファイルがありません-サーバーはそのURLを別のものとして選択し、本文データの処理方法を知るようにプログラムされています-保存ID 1234の下書きメールとして
したがって、メソッドの周囲で育ったレガシー互換性の巨大な重みを除いて、メソッドを排除することは確かに可能です。あなたが必要なもののためにそれらを使用するのが良いですが、それらをほとんど無視し、代わりにあなたの物事を機能させるために必要なものを何でも使用してください。私たちがアプリを作成したブラウザやサーバーにとって意味があることを覚えておく必要があるため、指定されたメソッドが必要です。クライアント側のスクリプトは、基盤となるブラウザーを使用してデータを送信する必要があります。ブラウザーが要求どおりに実行するメソッドを使用する必要があります-GETはすべての変数情報をパックするため、おそらくPOST多くのサーバーでは、URLとその長さに制限があります。クライアントはサーバーからの長い応答を望んでいます。HEADを使用しないでください。応答本文は想定されていないためです。たぶん、選択したブラウザとサーバーに制限はないかもしれませんが、おそらくいずれか一方が反対側で異なる実装に遭遇するでしょう-そして相互運用の精神で、仕様に固執することでよりうまく機能します
HTTPは、リモートプロシージャコールの一般的な原則の1つの特定のケースと考えることができます。要求の変数フィールドを使用して、必要なものをサーバーに通知すると、サーバーはそれに応じて応答します。現在、「Web 2.0」の複雑な双方向性により、これらの同じ機能がリクエストのすべてのフィールドに入力されています。URL、ヘッダー、本文、そして各アプリサーバーとアプリは独自の方法でそれらを理解しています。しかし、もともとWebはより単純で、静的ページを使用しており、HTTPメソッドは十分な対話性のレベルを提供するものと考えられていました。特に、HTTPには多くのメソッドが使用されていますが、RESTのおかげで一部のライトしか表示されないこともあります。例えば。 PUTとDELETEはRESTの前に瀕死であり、TRACEとPATCHはまだ見えていません。要点は、RPCのHTTPのモデルがその後に続くアプリと完全に一致せず、アプリがGETとPOSTだけで独自のモデルを実装したことですが、それまでにHTTPを捨てることはできませんでした。
RESTは、PUTとDELETEが返された場合、HTTPメソッドがほとんどのアプリの典型的なCRUDユースケースに対応することに注意して、提案されているものとは正反対のことを行いました。
また、HTTPメソッドにはセマンティクスが割り当てられており、ブラウザーやプロキシサーバーなどのミドルウェアがそれを尊重することに注意してください。POST、PUT、DELETE、およびPATCHリクエストには副作用があり、べき等ではない可能性があるため、クライアント側のアプリとミドルウェアには注意が必要です。ユーザーからの明示的なアクションなしにこれらのリクエストを発生させないため。実際には、不十分に設計されたWebアプリは、安全でないアクションにGETを使用しました。 Google Web Acceleratorプリフェッチャーは、このようなサイトで大量のデータを削除することによって問題を引き起こしました 、そのため、ベータ版はリリース直後に停止されました。
したがって、「できる」という質問に答えるには、サーバーアプリケーションに実行するアクションを通知するプロトコルに同意する必要があります。次に、URL/bodyのどこかに引数（たとえば、アクションのターゲットアイテム。アクションのセットは特定のアプリによってのみ制限されるため、拡張可能なプロトコルが必要です。ただし、安全なリクエストをクライアントアプリに通知し、おそらくキャッシュ制御などの他のニュアンスを考慮する必要があります。
開発者としての私の個人的な見地からすると、APIエンドポイントの作成がはるかに簡単になります。たとえば、Webサイトで製品を管理するコントローラーを作成すると、同じURLを使用して複数の異なる操作を実行できます。
例：
GET https://example.com/api/products/1234
これにより、製品1234の詳細が取得されます。
POST https://example.com/api/products/1234
これにより、リクエスト本文のデータを使用してID 1234の商品が作成されます。
PUT https://example.com/api/products/1234
これにより、製品1234がリクエスト本文のデータで更新されます。
DELETE https://example.com/api/products/1234
これにより、ID 1234の製品が削除されます。
操作ごとに異なるエンドポイントを作成することもできますが、その場合、プロセスが複雑になり、他の開発者が理解できなくなります。
GETやPOST HTTPプロトコルのようなメソッドの必要性は何ですか？
HTTPサーバーがfilesを提供するためだけに存在していた昔は忘れていたようです。スクリプト、CGIを実行していない、またはそのような動的コンテンツを作成していない。
リクエストメソッドは基本ですstandardized/ =の動詞のセット何をすべきかこれらのファイルで = ...
- GETはdownloadを意味します
- HEADは、/ get information ofを意味します
- PUTはuploadを意味します
- DELETEはremoveを意味します
- POSTは、/にデータを送信するを意味します
- OPTIONSは/私に何ができるか教えてを意味します
HTTP/0.9の日では、リクエスト行はtheプロトコルのリクエストレッグの唯一のものです。リクエストヘッダー、レスポンスヘッダーはありません。 GET /somefile、 押す Enter、サーバーは応答の本文（つまりHTMLコンテンツ）を返し、大丈夫です。さようなら（つまり、接続を閉じます）。
whyそれはこのように設計されました？私の答えは、それがもともと書かれていたためです当時存在していた種類のコンテンツ交換を処理するために、つまり、ユーザーの要求で静的HTMLファイルを提供する.
ただし、これらのセマンティクスの扱い方について質問する場合は、/現代のアプリケーションサーバー...
リクエストボディとレスポンスボディのみを使用してHTTPプロトコルを実装することはできませんか？
さまざまなHTTPメソッドの実装が本当に必要ですか？
私の答えは次のとおりです。やりたいことは何でもしますが、/すべきではありませんプロトコルの期待に反する：GETのような期待はデータを変更すべきではありません（または大まかに言えば、少なくとも べき等 結果が必要です）、HEADはGETと同じ結果になりますが、応答本文がない場合、PUTはターゲットURIのコンテンツを利用できるようにします（成功した場合）。
予想に反する場合その影響を慎重に考慮せずに、さまざまな不快なことが起こります...
- GETメソッドをデータ送信の使用に組み込むと、サーバーが顔に414 "URI Too Long"エラーを吐く場合があります。
- GETメソッドを使用してデータ変更を行うと、ユーザーがキャッシュプロキシの背後にいる場合、変更が反映されないことがあります。または、ユーザーがブックマークからURLを呼び出したとき（またはWebクローラーがURLに到達したとき）に予期しない変更が発生します。 。
- HEADメソッドに不適切に応答すると、自動サイトチェックツール（例：
wget --spider）サイトを保釈します。 - POSTメソッドをコンテンツのダウンロードに組み込むと、ブックマークしたり、ブラウザにURLを入力したりしても機能しません。
- などなど...
"初心者はルールを知っていますが、退役軍人は例外を知っています。"
とにかく、狭いユースケースのいくつかのルールに反する有効な言い訳を見つけることになるかもしれません。ただし、必ず調査を行い、すべての可能性を検討してください。そうしないと、相互運用性が損なわれ、「ユーザーエクスペリエンス」が台無しになってしまいます。
テストした主流の有名ブランドのクライアント/ユーザーエージェントの最新の光沢のあるロールアウトをユーザーが常に使用するという保証はありません。彼らは、自分のニーズ（私を含む）に合わせて調整された地元のブランド、隣の専門店から注文したカスタムブランド、または倉庫から掘り出したヴィンテージのブランドを使用できます。これらすべてを備えていても、サイトは相応のサービスを提供することが期待されています。それが私たちが基準を持っている理由です。
不注意に標準を破ることは、ユーザーにdiscriminationを適用することも意味します。
理論的には、私たちはあらゆる場所で使用でき、一種の作業になります。一部のソフトウェアでは、リクエストボディでGETを使用しています（elasticsearch/kibanaを調べています）。もちろん、これは恐ろしいことです。
最も重要な理由は、メソッドごとにセマンティクスが異なるためです。安全なものもあれば、べき等です。一部は両方です。 どれがどれかを確認
これは重要です。他のアプリケーションと対話するとき。 GETエンドポイントには副作用がないはずです。これは、Googleがあなたの側をクロールするときに重要です。 PUTはべき等であると想定されています。つまり、障害が発生した場合、クライアントは自由に再試行できます。これは、POSTの場合は当てはまりません。そのため、postリクエストでf5を押すと、ブラウザに醜い確認ボックスが必要になります。
また、GET、POSTなどを、同じ関数のオーバーロード、またはゲッターとセッターと考えることもできます。
GET_MyVar()は入力パラメーター（別名リクエスト本文）を取りませんが、何かを返します。
POST_MyVar(string blah)は、入力（ここでも、リクエスト本文）を使用して何かを実行し、何かを返すことがあります。 （また、関数が実行されたことがわかるように、少なくとも応答コードを返す必要があります!!）
DELETE_MyVar()また、おそらく何も取らず、何かを削除することが期待されます。
はい、すべてを次のように実装できます。MyVar(string Action, string? blah)
この方法では、1つの呼び出しのみを受け入れ、他のパラメーターに基づいて実行する処理を選択できます。
しかし、このアプローチの便利な点の1つは、ブラウザーとサーバーがこれらの動作を最適化できることです。たとえば、サーバーは_Action==DELETE_のすべてのリクエストをブロックする必要があるかもしれません。多分ブラウザは_Action==GET._の場所をキャッシュしたいと思うかもしれませんが、そうでなければ、すべての関数でif (Action==Delete) {return AngryFace}
プロトコルに従ってすべてを正確に実装する必要はありませんが、プロトコルは基本的に私たち全員が従うことにした一連のルールです。そうすれば、私がサーバーを見たことがない場合でも、サイトで何ができるか簡単に推測できます。
HTTPメソッドにはさまざまな目的があります。一般に、GETはダウンロード用、POSTはアップロード用です。
リクエストボディとレスポンスボディのみを使用してHTTPプロトコルの一部を実装する唯一の方法は、POSTを実装することです。 GETにはリクエストボディがありません。ヘッダーを含むリクエスト自体のみがあり、本文はありません。これは、ドキュメントをダウンロードするためのリクエストです。 POSTには、リクエストの本文（ファイルのアップロード）とレスポンスの本文（結果を示すドキュメント）の両方があります。
それで、POSTを実装して完了できますか？サイトを標準のブラウザで使用できるようにしたい場合はそうではありません。ブラウザが送信するデフォルトのリクエストタイプはGETです。 POSTリクエストは通常、Webページ内のフォームが送信されたとき、またはAJAX呼び出しに対してのみ送信されます。この特定のサーバーがAJAXの呼び出しにのみ使用され、ユーザーに表示されるページには使用されなかった場合にのみ、POSTのみで問題を回避できる可能性があります。
また、ブラウザはHEADリクエストを送信して、ドキュメントが最後にダウンロードされてから変更されているかどうかを確認する場合もあります。そのため、少なくともそれも実装することをお勧めします。
いずれにせよ、サイトにWebサーバーを最初から実装する正当な理由はありません。 HTTPプロトコルは複雑です。さまざまなメソッドに加えて、パイプライン処理とチャンク化されたリクエストも実装する必要があります。 Apache、Nginx、またはHTTPプロトコルを処理するIISなどのWebサーバー上にWebアプリケーションを構築する方がはるかに簡単です。サーブレットについて言及しているので、サーブレットを実行するTomcatまたはJBoss Webサーバーを使用する必要があります。
あなたが正しい、私たちはそれを行うことができます、GET、POST、PUTなどは、HTTPがPOSTメソッドだけで置き換えられ、他には何もない場合） GETを排除することは大きな仕事になることを認めてください。