HTTPメソッド GET/POST/PUT/DELETEなどを分かりやすく解説【初心者向け一覧】

Webサイトを見たり、オンラインサービスを使ったりする上で、私たちは知らず知らずのうちに「HTTPメソッド」というものを使っています。これは、私たちのパソコンやスマートフォン（クライアント）が、Webサイトのデータが置いてある場所（サーバー）に対して、「こういう操作をしたいです！」と伝えるための「お約束事」のようなものです。

「GET」「POST」「PUT」「DELETE」… IT関連の用語として、これらの単語を目にしたことがあるかもしれません。これらはHTTPメソッドの中でも特に代表的なものです。

この記事では、これらのHTTPメソッドが一体何のためにあり、それぞれどのような役割を持っているのかを、全くの初心者の方にも分かりやすく、そして詳細に解説していきます。Webの仕組みの基礎を知ることは、インターネットをもっと深く理解したり、自分でWebサイトやサービスを作る第一歩にも繋がります。

さあ、Webの世界を支える大切な「言葉」について、一緒に学んでいきましょう！

1. はじめに：Webを動かす「お願い」の言葉

インターネットを通じてWebサイトを見るとき、私たちのブラウザは舞台裏でサーバーと様々なやり取りをしています。例えば、「このページの情報をください」「このフォームに入力した内容を登録してください」「この情報を修正してください」「この情報を削除してください」といった、たくさんの「お願い」や「指示」をサーバーに送っています。

この「お願い」や「指示」の種類を示すのが「HTTPメソッド」です。HTTPメソッドは、サーバーに対して、「リソース（Webページ、画像、データなど）に対して、どんな操作をしたいのか？」を明確に伝えるためのものです。

イメージとしては、図書館で司書さんに話しかけるようなものです。

「〇〇という本を借りたいです」（GETメソッドのイメージ）
「読み終わった本を返したいです」（PUTメソッドの一部イメージ）
「新しい本を寄贈したいです」（POSTメソッドのイメージ）
「もう古くなった本を廃棄してください」（DELETEメソッドのイメージ）

このように、操作の内容によって言葉を使い分けるように、Webの世界でも操作の種類によってHTTPメソッドを使い分けているのです。

なぜこのような使い分けが必要なのでしょうか？それは、サーバーが受け取った「お願い」に対して、適切な処理を行い、正しい結果を返すためです。また、それぞれのメソッドが持つ特性（後述する「安全」や「べき等」といった性質）を理解し、適切に使い分けることは、効率的で信頼性の高いWebシステムやWeb APIを作る上で非常に重要になります。

この記事を通して、主要なHTTPメソッドとその役割、そしてWebの仕組みの基礎をしっかりと理解していきましょう。

2. HTTPとは何か？ HTTPメソッドの土台を理解する

HTTPメソッドを学ぶ前に、まずHTTPプロトコルそのものについて簡単に理解しておきましょう。

2-1. HTTP (Hypertext Transfer Protocol) とは？

HTTPは、Web上で情報をやり取りするために使われる、最も基本的な通信規約（プロトコル）の一つです。私たちがWebブラウザ（Chrome, Safari, Firefoxなど）でURLを入力してWebサイトを見たり、リンクをクリックしたりするとき、舞台裏ではこのHTTPが使われています。

HTTPの基本的な流れは以下の通りです。

クライアントがリクエストを送信する: Webブラウザなどの「クライアント」が、サーバーに対して「この情報が欲しい」「このデータを送りたい」といった「お願い」をします。これを「HTTPリクエスト」と呼びます。
サーバーがレスポンスを返す: リクエストを受け取ったWebサーバーは、その内容に応じて処理を行い、「お願い」された情報や処理結果を「クライアント」に送り返します。これを「HTTPレスポンス」と呼びます。

この「HTTPリクエスト」の中に、これから詳しく見ていく「HTTPメソッド」が含まれています。

2-2. クライアントとサーバー

クライアント: 情報を受け取る側、または操作を要求する側です。通常は、皆さんが使っているWebブラウザ（PCやスマホ）や、サーバーと通信するプログラムなどを指します。
サーバー: 情報を提供する側、または要求された操作を処理する側です。Webサイトのデータやプログラムが置かれているコンピューターなどを指します。

クライアントとサーバーは、このHTTPプロトコルを使って対話しています。

2-3. リソースとURI

HTTPは、「リソース」と呼ばれるWeb上の情報のかたまりを操作するためのプロトコルです。リソースとは、Webページ、画像ファイル、動画、APIから取得できるデータなど、Web上で識別・操作できるあらゆるものを指します。

そして、そのリソースがどこにあるかを示す住所が「URI (Uniform Resource Identifier)」です。よく目にするURL (Uniform Resource Locator) は、URIの一種です。

例えば、「https://example.com/products/123」というURLは、example.comというサーバーにある、products/123というパスで識別される「商品番号123番」のリソースを指し示しています。

HTTPリクエストでは、「どのURIのリソースに対して」「どんなHTTPメソッドで」操作したいのかをサーバーに伝えます。

2-4. HTTPリクエストの構成要素

HTTPリクエストは主に以下の要素で構成されます。

HTTPメソッド: これから詳しく解説する、操作の種類（GET, POSTなど）。
URI: 操作の対象となるリソースの場所（パス）。
HTTPバージョン: 使用するHTTPのバージョン（例: HTTP/1.1, HTTP/2）。
ヘッダー (Headers): リクエストに関する様々な追加情報を含みます。例えば、クライアントの種類（User-Agent）、受け付け可能なデータの種類（Accept）、認証情報（Authorization）、Cookieなどが含まれます。
ボディ (Body): POSTやPUTメソッドなどで、サーバーに送りたいデータそのものを格納する部分です。フォームの入力内容や、アップロードするファイルなどがここに含まれます。

2-5. HTTPレスポンスの構成要素

HTTPレスポンスは主に以下の要素で構成されます。

HTTPバージョン: 使用するHTTPのバージョン。
ステータスコード (Status Code): リクエストが成功したか、失敗したか、どのような種類の結果になったかを示す3桁の数字コード（例: 200 OK, 404 Not Found, 500 Internal Server Error）。
ステータステキスト (Status Text): ステータスコードに対応する短い説明（例: OK, Not Found）。
ヘッダー (Headers): レスポンスに関する様々な追加情報を含みます。サーバーの種類、コンテンツの種類（Content-Type）、コンテンツの長さ（Content-Length）、キャッシュに関する情報などが含まれます。
ボディ (Body): クライアントが要求したリソースのデータ本体（WebページのHTML、画像データ、APIからのJSONデータなど）が含まれます。

HTTPメソッドは、この「HTTPリクエスト」の最初の行に書かれる、非常に重要な要素なのです。

3. HTTPメソッドとは？リソースへの「命令」

あらためて、HTTPメソッドとは、クライアントがサーバー上の「リソース」に対して行いたい「操作の種類」を伝えるための命令です。

例えば、

GET /products/123 HTTP/1.1
- メソッド: GET
- URI: /products/123
- 意味: /products/123というリソースの情報をください。
POST /users HTTP/1.1
- メソッド: POST
- URI: /users
- 意味: /usersという場所（おそらくユーザーリスト）に、リクエストボディに含まれる新しいユーザー情報を追加してください。
PUT /users/456 HTTP/1.1
- メソッド: PUT
- URI: /users/456
- 意味: /users/456というリソースを、リクエストボディに含まれる情報でまるごと更新してください。もし存在しなければ、その内容で新しく作成してください。
DELETE /products/789 HTTP/1.1
- メソッド: DELETE
- URI: /products/789
- 意味: /products/789というリソースを削除してください。

このように、メソッドによって、リソースに対する操作の意図が明確に示されます。

3-1. Web APIにおけるHTTPメソッドの重要性

近年、Webサービスやアプリケーション開発において「Web API (Application Programming Interface)」が非常に重要になっています。Web APIは、異なるソフトウェア同士がインターネットを通じて連携するための窓口です。

多くのWeb APIは、このHTTPプロトコルとHTTPメソッドを効果的に活用して設計されています。特に、「RESTful API」と呼ばれる設計スタイルでは、HTTPメソッドをリソースに対する標準的な操作（CRUD: Create, Read, Update, Delete）に対応させて使用することが推奨されています。

Read (読み込み): GET メソッド
Create (作成): POST メソッド
Update (更新): PUT または PATCH メソッド
Delete (削除): DELETE メソッド

このように、HTTPメソッドを適切に使い分けることは、Web APIを使う側も作る側も、そのAPIが「何をするものなのか」を理解しやすくなり、設計の一貫性を保つために非常に重要なのです。

3-2. HTTPメソッドの分類：安全性とべき等性

HTTPメソッドを理解する上で、以下の2つの重要な性質を知っておく必要があります。これらは、それぞれのメソッドが「どのような操作に適しているか」「操作の結果がどうなるか」を示す指標となります。

安全 (Safe): そのメソッドを実行しても、サーバー側のリソースの状態が変化しない性質を指します。単に情報を取得するだけで、サーバー上のデータが書き換えられたり、削除されたりしない操作です。GETやHEADメソッドは「安全」なメソッドです。一方、POST, PUT, DELETEなどのメソッドは、リソースの状態を変更する可能性があるため「安全ではない」メソッドです。安全なメソッドは、例えばブラウザのリロードボタンを押したり、ページのプリフェッチ（先読み）を行ったりしても問題がありません。
べき等 (Idempotent): 同じリクエストを何度繰り返しても、サーバー側のリソースの状態が最初の1回目のリクエストを実行した後の状態と変わらない性質を指します。ただし、レスポンスの内容自体は変わる可能性があります（例: 削除済みのリソースをもう一度削除しようとした場合、1回目は「成功」だが2回目以降は「存在しない」となるが、リソースの状態は「削除済み」という点で同じ）。GET, HEAD, PUT, DELETEメソッドは「べき等」なメソッドです。POSTメソッドは通常「べき等ではない」とされています（例: 同じ情報を何度もPOSTすると、その都度新しいリソースが作成される可能性がある）。

これらの性質は、システムの信頼性やキャッシュの扱いに影響するため、メソッドの選択において非常に重要です。

それでは、いよいよ主要なHTTPメソッドを一つずつ詳しく見ていきましょう。

4. 主要なHTTPメソッド徹底解説

ここでは、Web開発で最も頻繁に使われる主要な4つのメソッド、GET、POST、PUT、DELETEについて、それぞれの詳細を解説します。

4-1. GETメソッド

役割: リソースの取得
一言で言うと: 「サーバーさん、この情報ください！」

GETメソッドは、指定したURIにあるリソースの情報をサーバーから取得するために使用されます。WebブラウザでURLを入力してアクセスしたり、リンクをクリックしたりするほとんどの場合、このGETメソッドが使われています。

4-1-1. 詳細な操作内容

クライアントは取得したいリソースのURIを指定してGETリクエストを送信します。サーバーはリクエストされたURIに対応するリソースを見つけ出し、その内容（HTMLファイル、画像ファイル、データなど）をHTTPレスポンスのボディに含めてクライアントに返します。

4-1-2. 安全性（Safe）とべき等性（Idempotent）

安全: はい、GETメソッドは安全です。GETリクエストは、サーバー上のリソースの状態を変化させることを意図していません。単に情報を読み取るだけです。
べき等: はい、GETメソッドはべき等です。同じGETリクエストを何度実行しても、サーバー側のリソースの状態は変わりませんし、同じリソースがあれば常に同じ内容を取得できるはずです。

4-1-3. リクエストの構成要素

GETリクエストでは、サーバーに情報を伝える必要がある場合、主にURIの「クエリ文字列（Query String）」を使用します。

URI: 操作の対象となるリソースのパス。
クエリ文字列: URIの末尾に ? を付け、その後に キー=値 の形式で情報を記述します。複数の情報を送る場合は & で繋ぎます。
例: /search?keyword=HTTP&category=web
この例では、keyword が HTTP、category が web という情報をサーバーに伝えています。これは、検索条件などをサーバーに送る際によく使われます。
ボディ: 通常、GETリクエストにボディは含まれません。リクエストボディにデータを含めても、多くのサーバーや仕様では無視されます。

4-1-4. 典型的な利用シーン

Webページの表示（HTML, CSS, JavaScriptファイルの取得）
画像の表示
検索結果の表示（検索キーワードをクエリ文字列で渡す）
Web APIで特定のデータを取得する（例: ユーザー一覧を取得する /users、特定のユーザー情報を取得する /users/123）
ファイルのダウンロード

4-1-5. ブラウザでの挙動

アドレスバーにURLを入力してアクセス
リンクをクリック
ブックマークからのアクセス
ブラウザの「戻る」「進む」「更新」ボタン

これらの操作は、基本的にGETリクエストを発行します。

4-1-6. 注意点・推奨される使い方

機密情報や個人情報をクエリ文字列で渡さない: クエリ文字列はブラウザの履歴に残ったり、サーバーのログに記録されたり、Refererヘッダーとして他のサイトに送られたりする可能性があるため、パスワードやクレジットカード番号などの機密情報をGETで送信するのは絶対に避けるべきです。
大きなデータの送信には不向き: クエリ文字列の長さには制限があります（ブラウザやサーバーによって異なりますが、一般的に数KB程度）。大量のデータを送信したい場合はGETではなくPOSTを使用します。
サーバーの状態を変更する操作には使わない: GETはあくまで「取得」のためのメソッドです。「安全」な操作にのみ使用するべきです。例えば、「商品をカートに入れる」といった操作をGETで行うと、ユーザーが意図せずページを再読み込みしたり、検索エンジンのクローラーがリンクを辿ったりするだけで商品がカートに入ってしまう可能性があります。

4-1-7. 関連するステータスコード例

200 OK: リクエストは成功し、リソースがレスポンスボディに含まれています。
404 Not Found: リクエストされたリソースが見つかりませんでした。
304 Not Modified: クライアントが持つキャッシュは最新であり、リソースを再送信する必要がありません。

4-1-8. 具体的なHTTPリクエスト例（概念）

GET /products/123 HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (...) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: ja,en-US;q=0.7,en;q=0.3 Connection: keep-alive
（ボディはありません）

これは、example.com の /products/123 というリソースを、HTTP/1.1プロトコルを使って取得するリクエストです。ヘッダーにはクライアントの情報や、受け付け可能なデータの種類などが含まれています。

GETメソッドは最もシンプルで基本的なメソッドであり、Webの「見る」「読む」といった操作の根幹をなしています。

4-2. POSTメソッド

役割: サーバーにデータを送信する（リソースの作成、データの送信など）
一言で言うと: 「サーバーさん、このデータを受け取って何か処理してください！」

POSTメソッドは、クライアントからサーバーにデータを送信するために使用されます。その用途は非常に幅広く、新しいリソースの作成、既存リソースの更新、特定の処理の実行など、GETではできない「サーバーの状態を変更する可能性のある操作」によく使われます。

4-2-1. 詳細な操作内容

POSTリクエストでは、サーバーに送りたいデータをリクエストボディに格納して送信します。送信されたデータは、指定されたURIのリソースに関連付けられた処理で利用されます。

例えば、掲示板に新しい記事を投稿する場合、記事のタイトルや本文といったデータはPOSTリクエストのボディに含まれて、掲示板のURI（例: /board/post）に対して送信されます。サーバーは受け取ったデータを使って新しい記事リソースを作成します。

GETが「〇〇の情報ください」と具体的にリソースを指定して取得するのに対し、POSTは「このデータをここに送るので、サーバー側でよしなに処理してください」というイメージです。

4-2-2. 安全性（Safe）とべき等性（Idempotent）

安全: いいえ、POSTメソッドは安全ではありません。通常、POSTリクエストはサーバー上のリソースの状態を変更することを意図しています（新しいリソースの作成、データベースの更新など）。
べき等: いいえ、POSTメソッドは通常べき等ではありません。同じPOSTリクエストを繰り返し実行すると、その都度異なる結果が生じる可能性があります。例えば、ユーザー登録フォームを何度も送信すると、ユーザーが重複して登録されてしまうことがあります。

4-2-3. リクエストの構成要素

POSTリクエストの最も重要な構成要素は「ボディ」です。

URI: データを送信する対象となるURI。これは、新しく作成されるリソースそのものを指すのではなく、そのリソースを作成するための「エンドポイント」（窓口）や、データを受け取って処理するプログラムなどを指すことが多いです（例: /users で新しいユーザーを作成、/orders で新しい注文を作成）。
クエリ文字列: POSTでもクエリ文字列を使用することは可能ですが、重要なデータは通常ボディで送信します。検索条件など、補助的な情報に使うことがあります。
ボディ: サーバーに送信するデータ本体を格納します。データの形式は多岐にわたりますが、HTMLフォームのデータ（application/x-www-form-urlencoded や multipart/form-data）、JSON形式のデータ（application/json）、XML形式のデータ（application/xml）、ファイルデータなど、ヘッダーのContent-Typeで指定されます。

4-2-4. 典型的な利用シーン

Webフォームの送信（ユーザー登録、ログイン、お問い合わせ、コメント投稿など）
新しいリソースの作成（例: 商品データの追加、記事の投稿）
ファイルのアップロード
特定の処理の実行（例: 注文の確定、メール送信要求）
Web APIでのデータの送信や操作（例: 新しいユーザーの作成 /users、特定のユーザーへのメッセージ送信 /users/123/message）

4-2-5. ブラウザでの挙動

<form method="post"> で指定されたフォームを送信したとき
JavaScript（Ajaxなど）でPOSTリクエストを送信したとき

ブラウザのアドレスバーに直接URLを入力したり、リンクをクリックしたりしてもPOSTリクエストは発行されません。

4-2-6. 注意点・推奨される使い方

サーバーの状態を変更する操作に使う: 安全ではない操作（作成、更新、削除、その他処理）に主に使います。
大きなデータや機密情報の送信に適している: データはボディに含まれるため、クエリ文字列のような長さ制限は実質的にありません（サーバー側の設定による制限はあり得ます）。また、HTTPSと組み合わせれば、ボディ内のデータは暗号化されるため、GETのクエリ文字列よりも安全に機密情報を送信できます。
べき等ではない操作に注意: ユーザーがPOSTリクエストを送信した後で、ブラウザの「更新」ボタンを押したり、複数回クリックしたりすると、意図せず同じ処理が繰り返し実行されてしまう可能性があります。これを防ぐために、サーバー側で重複送信をチェックしたり、処理完了後にGETリクエストで別のページにリダイレクトしたりするなどの対策が必要です。

4-2-7. 関連するステータスコード例

200 OK: リクエストが成功し、サーバーが意図した処理を実行しました。レスポンスボディには処理結果が含まれることがあります。
201 Created: リクエストの結果、新しいリソースが正常に作成されました。レスポンスヘッダーのLocationフィールドに新しく作成されたリソースのURIが含まれることがあります。
204 No Content: リクエストは成功しましたが、返すコンテンツ（レスポンスボディ）はありません。
400 Bad Request: リクエストの形式が不正であるなど、サーバーがリクエストを処理できません。
409 Conflict: リクエストは現在のリソースの状態と競合しています（例: すでに存在するリソースを作成しようとした場合）。

4-2-8. 具体的なHTTPリクエスト例（概念）

“`
POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 50

{
“name”: “山田太郎”,
“email”: “[email protected]”
}
`` これは、example.comの/usersに対して、新しいユーザー情報（JSON形式）を送信するPOSTリクエストです。ボディに実際のユーザーデータが含まれています。Content-Type`ヘッダーは、ボディのデータ形式がJSONであることを示しています。

POSTメソッドは、Webが単なる情報閲覧だけでなく、「参加」したり「操作」したりできるインタラクティブなものであるために不可欠なメソッドです。

4-3. PUTメソッド

役割: 指定したURIのリソースの更新、または存在しない場合は作成
一言で言うと: 「サーバーさん、この場所の情報を、これでまるごと置き換えてください！ もし無ければ新しく作って。」

PUTメソッドは、指定されたURIに存在するリソースを、リクエストボディに含まれる内容で完全に置き換えるために使用されます。もし指定されたURIにリソースが存在しない場合は、そのURIで新しいリソースを作成します。

4-3-1. 詳細な操作内容

クライアントは更新または作成したいリソースのURIを明確に指定し、そのリソースの最終的な内容をリクエストボディに含めてPUTリクエストを送信します。サーバーは、指定されたURIを調べ、リソースがあればボディの内容で上書きし、なければボディの内容で新しいリソースを作成します。

POSTが「（場所はここだけど）このデータを基に何かよろしく処理して」という命令に近いのに比べ、PUTは「このURIを、このボディの内容と全く同じ状態にしてください」という命令になります。

4-3-2. 安全性（Safe）とべき等性（Idempotent）

安全: いいえ、PUTメソッドは安全ではありません。リソースの内容を変更したり、新しく作成したりするためです。
べき等: はい、PUTメソッドはべき等です。同じPUTリクエストを何度実行しても、指定されたURIのリソースは常にリクエストボディに含まれる内容と全く同じ状態になります。1回実行しても、10回実行しても、最終的な結果（リソースの状態）は同じです。

4-3-3. リクエストの構成要素

PUTリクエストのボディには、更新または作成後のリソースの完全な内容を含めます。

URI: 更新または作成の対象となる具体的なリソースのURIを指定します（例: /users/123, /products/abc）。これは、リソースのコレクション全体（例: /users）ではなく、個々のリソースを指す必要があります。
ボディ: 更新または作成後のリソースの完全なデータを含みます。形式はJSONやXMLなど、APIの仕様によって異なります。

4-3-4. 典型的な利用シーン

Web APIで特定の既存リソースを完全に更新する（例: ユーザー番号123番の登録情報を全て更新する /users/123）
サーバー上に指定した名前でファイルをアップロードする（例: /files/document.pdf としてファイルをアップロードする）
設定ファイルなどを特定のパスに配置・更新する

4-3-5. ブラウザでの挙動

通常のブラウザ操作（リンククリック、フォーム送信）ではPUTリクエストは発行されません。主にJavaScript（Ajax, Fetch APIなど）や、コマンドラインツール（Curlなど）を使ってWeb APIと連携する際に使用されます。

4-3-6. 注意点・推奨される使い方

リソース全体を置き換える: PUTはリソースの部分的な更新には向きません。もしリソースの一部だけを更新したい場合は、後述するPATCHメソッドを検討してください。
URIは個々のリソースを指す: コレクション全体（例: /users）に対してPUTを使用することは一般的ではありません。個々のリソース（例: /users/123）を指定して使用します。
べき等性を活用する: ネットワークエラーなどでPUTリクエストが再送されても問題がないように、べき等性を前提としたサーバー側の設計が重要です。

4-3-7. 関連するステータスコード例

200 OK: リソースの更新が成功しました。
201 Created: リソースが存在せず、新しく作成されました。
204 No Content: リソースの更新/作成は成功しましたが、返すコンテンツ（レスポンスボディ）はありません。
400 Bad Request: リクエストの形式が不正など。
404 Not Found: 更新対象のリソースが見つからなかった（ただし、PUTは作成も兼ねるので、この場合は201になることが多い）。
409 Conflict: リクエストがリソースの現在の状態と競合している。

4-3-8. 具体的なHTTPリクエスト例（概念）

“`
PUT /users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 55

{
“name”: “田中花子”,
“email”: “[email protected]”,
“address”: “東京都”
}
`` これは、example.comの/users/123というリソース（おそらくユーザー番号123番の情報）を、ボディに含まれるJSONデータで完全に置き換えるPUTリクエストです。もし/users/123`がなければ、この内容で新しく作成されます。

PUTメソッドは、特定の状態にリソースを「設定する」といった操作に適しており、そのべき等性から信頼性の高い更新処理を実装するのに役立ちます。

4-4. DELETEメソッド

役割: 指定したURIのリソースの削除
一言で言うと: 「サーバーさん、この場所の情報、削除してください！」

DELETEメソッドは、指定されたURIにあるリソースをサーバーから削除するために使用されます。

4-4-1. 詳細な操作内容

クライアントは削除したいリソースのURIを指定してDELETEリクエストを送信します。サーバーは指定されたURIのリソースを見つけ出し、それを削除します。

4-4-2. 安全性（Safe）とべき等性（Idempotent）

安全: いいえ、DELETEメソッドは安全ではありません。リソースを削除するため、サーバーの状態を変化させます。
べき等: はい、DELETEメソッドはべき等です。同じDELETEリクエストを何度実行しても、リソースの状態は「削除済み」という最終状態から変わりません。1回目でリソースが削除された後、2回目以降は「すでに存在しない」という結果になりますが、リソースは引き続き「削除済み」の状態です。（ただし、レスポンスコードは変わる可能性があります。1回目は200 OKや204 No Content、2回目以降は404 Not Foundなど。）

4-4-3. リクエストの構成要素

DELETEリクエストは、削除対象のリソースをURIで指定します。

URI: 削除の対象となる具体的なリソースのURIを指定します（例: /users/123, /products/abc）。
ボディ: 通常、DELETEリクエストにボディは含まれません。サーバーによってはボディのデータを処理するものもありますが、一般的ではありません。

4-4-4. 典型的な利用シーン

Web APIで特定の既存リソースを削除する（例: ユーザー番号123番のアカウントを削除する /users/123）
サーバー上のファイルを削除する（例: /files/old_document.txt を削除する）

4-4-5. ブラウザでの挙動

通常のブラウザ操作ではDELETEリクエストは発行されません。主にJavaScript（Ajax, Fetch APIなど）や、コマンドラインツール（Curlなど）を使ってWeb APIと連携する際に使用されます。Webサイトで削除機能を提供する場合は、DELETEメソッドを使う代わりに、POSTメソッドで削除指示を送り、サーバー側で処理を行うことも多いですが、RESTfulな設計ではDELETEを使用することが推奨されます。

4-4-6. 注意点・推奨される使い方

URIは個々のリソースを指す: PUTと同様、コレクション全体に対してDELETEを使用することは一般的ではありません。個々のリソースを指定して使用します。
べき等性を前提とした設計: 複数回DELETEリクエストが送信されても問題ないようにサーバー側を設計します。
本当に削除して良いかの確認: DELETEは不可逆な操作であるため、API設計においては、削除前に確認ステップを設けたり、論理削除（データは残すが、利用不可にする）を採用したりすることも検討が必要です。

4-4-7. 関連するステータスコード例

200 OK: リソースの削除が成功し、その結果がレスポンスボディに含まれています。
202 Accepted: 削除リクエストは受け付けられましたが、処理は非同期で行われます（削除が完了するまで時間がかかる場合など）。
204 No Content: リソースの削除は成功しましたが、返すコンテンツ（レスポンスボディ）はありません。これが最も一般的です。
404 Not Found: 削除対象のリソースが見つかりませんでした。
409 Conflict: リソースが他のリソースに依存しているなど、削除できない状態です。

4-4-8. 具体的なHTTPリクエスト例（概念）

DELETE /users/123 HTTP/1.1 Host: example.com
（ボディはありません）

これは、example.com の /users/123 というリソース（ユーザー番号123番の情報）を削除するDELETEリクエストです。非常にシンプルで、削除対象はURIで明確に指定されます。

DELETEメソッドは、Web APIにおける「リソースの消去」という明確な目的で使用されます。

5. その他のHTTPメソッド（概要と使いどころ）

主要な4つのメソッド以外にも、HTTPにはいくつかのメソッドが定義されています。ここでは、比較的よく使われるものについて簡単に紹介します。

5-1. HEADメソッド

役割: リソースのヘッダー情報のみを取得
安全: はい
べき等: はい
詳細: GETメソッドとほぼ同じですが、サーバーはレスポンスボディを返しません。リクエストされたリソースのヘッダー情報（最終更新日時、コンテンツの種類、コンテンツの長さなど）だけを取得したい場合に役立ちます。
使いどころ:
- リソースの存在確認（ステータスコードを確認する）
- リソースが更新されているかどうかの確認（Last-Modifiedヘッダーなどを確認する）
- リソースのサイズやタイプなどのメタデータを確認する

5-2. OPTIONSメソッド

役割: 対象のリソースで利用可能なHTTPメソッドを取得
安全: はい
べき等: はい
詳細: 指定したURIのリソースに対して、クライアントがどのようなHTTPメソッド（GET, POSTなど）を実行できるか、あるいはサーバーが受け付け可能なメソッドは何かをサーバーに問い合わせます。サーバーはレスポンスヘッダーのAllowフィールドに、許可されているメソッドのリストを含めて返します。
使いどころ:
- クライアントが特定の操作（例: PUT）が可能か事前に確認する。
- 特に、クロスオリジンリソース共有（CORS: Cross-Origin Resource Sharing）において、ブラウザが実際のデータ送信リクエスト（POSTやPUTなど）の前に、サーバーがその送信元からのリクエストを受け付けるかを確認するための「プリフライトリクエスト」として OPTIONS が使われます。

5-3. PATCHメソッド

役割: リソースの部分的な更新
安全: いいえ
べき等: 通常はいいえ（ただし、パッチの適用方法によってはべき等になりうる）
詳細: PUTメソッドがリソース全体を置き換えるのに対し、PATCHメソッドはリソースの一部のみを変更するために使用されます。リクエストボディには、リソースをどのように変更したいかを示す「パッチ」情報が含まれます。パッチ情報の形式にはいくつかの種類があります（例: JSON Patch, JSON Merge Patch）。
使いどころ:
- Web APIでリソースの一部だけを効率的に更新したい場合（例: ユーザー情報のニックネームだけを変更したい場合、他の情報を全てPUTで送り直すのは非効率的であり、間違って他の情報を消してしまうリスクもあるため、PATCHでニックネームの変更だけを指示する）。

5-4. その他のメソッド

TRACE: リクエストがサーバーに到達するまでの経路（プロキシなど）をトレースします。デバッグ目的で使用されることがありますが、セキュリティ上の理由から無効にされていることもあります。
CONNECT: プロキシサーバーを経由してSSL/TLS暗号化された通信トンネルを確立するために使用されます。HTTPS通信などで利用されます。

これらのメソッドは主要な4つほど頻繁に使われるわけではありませんが、特定の目的のために存在しており、Webプロトコルの柔軟性を示しています。初心者の方は、まずはGET, POST, PUT, DELETEの4つをしっかり理解することが重要です。

6. HTTPメソッドの使い分けの実践的なポイント

ここまで、主要なHTTPメソッドそれぞれの役割や特性を見てきました。これらのメソッドを適切に使い分けることが、効率的で理解しやすく、そして信頼性の高いWebシステムやWeb APIを構築する上で非常に重要になります。

ここでは、メソッドを使い分ける上での実践的なポイントをまとめます。

6-1. 操作の種類とメソッドを対応させる（RESTfulの考え方）

最も基本的な使い分けの考え方は、その操作が「リソースに対して何をするものなのか」に応じてメソッドを選択することです。RESTful APIの考え方が非常に参考になります。

情報の取得: 単にサーバーからデータを読みたいだけ ⇒ GET
- 例: ユーザー一覧を見る、特定の商品詳細を見る、検索結果を表示する
新しい情報の作成: サーバーに新しいデータを提供して、リソースを新しく作ってほしい ⇒ POST
- 例: 新しいユーザーを登録する、商品をカートに入れる（※）、新しい記事を投稿する
- ※「商品をカートに入れる」は、新しい「カートアイテム」というリソースを作成する操作とみなせます。
既存の情報の完全な更新: 特定の場所（URI）にある情報を、新しい内容でまるごと置き換えたい ⇒ PUT
- 例: ユーザーのプロフィール情報を全て書き換える、設定ファイルを上書きする
既存の情報の部分的な更新: 特定の場所（URI）にある情報の一部だけを変更したい ⇒ PATCH
- 例: ユーザーのニックネームだけを変更する、記事の公開/非公開ステータスを切り替える
既存の情報の削除: 特定の場所（URI）にある情報を消したい ⇒ DELETE
- 例: ユーザーアカウントを削除する、カートから商品を削除する

6-2. 安全性（Safe）を意識する

GETメソッドは安全なメソッドです。これは非常に重要な特性です。

安全な操作はGETを使う: サーバーの状態を変えない操作（情報の表示など）には、必ずGETメソッドを使用しましょう。これにより、ブラウザのキャッシュが有効に利用されたり、ユーザーが「戻る」「更新」をしても予期しない結果にならないことが保証されます。
安全ではない操作にGETを使わない: サーバーの状態を変更する可能性のある操作（データの登録、更新、削除など）にGETメソッドを使用するのは避けてください。前述の通り、意図しない操作実行のリスクがあります。

6-3. べき等性（Idempotent）を理解して活用する

GET, HEAD, PUT, DELETEメソッドはべき等です。

べき等な操作にべき等なメソッドを使う: 同じ操作を複数回実行しても結果が変わらない性質の操作には、べき等なメソッド（GET, PUT, DELETE）を使うのが自然です。特にネットワークが不安定な状況でリクエストが再送される可能性がある場合、べき等性が保証されているとシステムの信頼性が高まります。例えば、PUTでユーザー情報を更新するリクエストがタイムアウトして再送されても、ユーザー情報が複数回書き換わって意図しない状態になることはありません（常に指定した内容になります）。
べき等ではない操作にはPOSTを使うことが多い: 新規作成など、同じリクエストが複数回実行されると困る操作にはPOSTを使用します。ただし、POSTはべき等ではないため、サーバー側で重複送信の防止策などが必要になる場合があります。

6-4. GETとPOSTの使い分け（データの送信について）

特に初心者の方が迷いがちなのが、GETとPOSTのどちらでデータを送るかです。

データの取得 ⇒ GET: 検索キーワードなど、取得する情報を絞り込むためのデータはクエリ文字列でGETリクエストに含めるのが一般的です。
データの送信（作成・更新・その他処理） ⇒ POST: 新規登録データ、ログイン情報、ファイルアップロードなど、サーバーに渡して何らかの処理をしてもらいたいデータは、リクエストボディに含めてPOSTリクエストで送信するのが基本です。

理由:
* データ量: GETのクエリ文字列は長さ制限があるため、大量のデータ送信には不向きです。POSTのボディには実質的な制限はありません。
* セキュリティ: GETのクエリ文字列はURLの一部として扱われ、ブラウザの履歴やサーバーログに残ります。POSTのボディはこれらに残りません。機密情報や個人情報を送る際は必ずPOSTを使用し、さらにHTTPSで通信を暗号化することが不可欠です。
* 目的の明確化: GETはあくまで「取得」であり、ボディを含むべきではありません。データを送信してサーバーに処理させるのはPOSTの役割です。

6-5. PUTとPATCHの使い分け

リソース全体を置き換える ⇒ PUT: リソースの状態を指定した内容に「設定する」イメージです。
リソースの一部だけを変更する ⇒ PATCH: リソースに対して「こういう変更を加えてほしい」という指示を送るイメージです。

PATCHの方がより細かい制御が可能で、送信データ量も少なく済みますが、サーバー側での実装が複雑になる場合があります。APIの設計方針や、更新の粒度によって使い分けます。

6-6. HTTPメソッドは「何をしたいか」を明確に伝える

HTTPメソッドは、クライアントがサーバーに対して「このリソースに対して、こういう意図で操作したいです」と明確に伝えるための「標準的な言葉」です。この言葉を正しく使うことで、クライアントもサーバーも互いの意図を理解しやすくなり、システム全体の設計が整理され、メンテナンス性が向上します。

例えば、商品を削除するAPIをGETメソッドで実装した場合、APIの利用者から見ると「GETなのに削除されるの？」と混乱が生じます。しかし、DELETEメソッドで実装されていれば、「あ、これはリソースを削除するためのAPIだな」と直感的に理解できます。

7. よくある疑問と落とし穴

HTTPメソッドを学ぶ上で、あるいは実際に使用する上で、よくある疑問や注意すべき点があります。

7-1. 「GETでデータを送るのはなぜダメなの？」

前述の通り、GETメソッドで重要なデータや大量のデータを送るのは推奨されません。主な理由は以下の通りです。

セキュリティ: クエリ文字列（URLに含まれるデータ）はブラウザの履歴、サーバーログ、プロキシのログなどに平文で残ります。パスワードなどの機密情報をこれで送ると、簡単に漏洩する危険があります。
長さの制限: クエリ文字列の長さにはブラウザやサーバーによって上限があります。大量のデータを送ることはできません。
キャッシュ: GETリクエストはキャッシュされることがあります。同じURL（＝同じデータを含むクエリ文字列）へのアクセスに対して、サーバーにリクエストが送られず、ブラウザやプロキシに残っている古いデータが表示されてしまう可能性があります。サーバーの状態を変える操作（例: カートへの追加）をGETで行った場合、キャッシュによって操作が実行されなかったり、逆に意図せず何度も実行されてしまったりするリスクがあります。
ブックマーク・共有: URLにデータが含まれるため、意図せずデータをブックマークされたり、他の人に共有されてしまったりする可能性があります。

これらの理由から、データの送信やサーバーの状態を変更する操作にはPOSTメソッドを使用するのが適切です。

7-2. 「POSTで何でもできるなら、GET以外はPOSTで統一してもいいのでは？」

技術的には、POSTリクエストのボディに操作内容や対象リソースを示す情報を含めることで、「新規作成」「更新」「削除」など、様々な操作をPOST一つで行うことは可能です。実際、かつてのWebシステムや、一部のRPC (Remote Procedure Call) スタイルのAPIでは、POSTを何でも屋として使用することがありました。

しかし、これはRESTfulな設計思想からは外れており、以下のようなデメリットがあります。

意図が不明確: リクエストを見ただけでは「何をする操作なのか」が分かりにくくなります。APIの利用者は、ドキュメントを読まないと具体的な操作内容を理解できません。
標準的な特性を活用できない: 安全性やべき等性といったHTTPメソッドの標準的な特性（キャッシュの利用、安全なリトライなど）を活かすことができません。例えば、単なる情報取得（本来GETを使うべき操作）をPOSTで行うと、キャッシュが利用できず、サーバー負荷が増加する可能性があります。
ツールやフレームワークとの連携: 多くのWeb開発フレームワークやAPIツールは、HTTPメソッドとその標準的な役割（GET=取得、POST=作成など）を前提として設計されています。POSTを多用途に使うと、これらのツールやフレームワークが提供する便利な機能を活用しにくくなることがあります。

POSTメソッドは、あくまで「サーバーにデータを送信して、そのデータを使って何か処理を行う」という汎用的な役割を担いますが、リソースに対するCRUD操作の意図を明確にするためには、可能な限りGET, PUT, DELETE, PATCHといった他のメソッドを適切に使い分けることが推奨されます。

7-3. 「べき等性って、DELETEで削除した後にまたDELETEしたらエラーになるからべき等じゃないのでは？」

べき等性の定義は、「同じリクエストを繰り返しても、リソースの最終状態が最初の1回を実行した後の状態と同じであること」です。

DELETEメソッドの場合、1回目のDELETEリクエストでリソースは「削除済み」状態になります。2回目以降のDELETEリクエストを実行しても、リソースは引き続き「削除済み」状態であり、それ以上状態は変わりません。したがって、DELETEはべき等です。

レスポンスの内容（ステータスコードなど）が毎回同じである必要はありません。1回目は「削除成功 (200/204)」、2回目以降は「見つからない (404)」となるのが典型的ですが、それでもリソースの状態は「削除済み」で変化しないため、べき等性は保たれています。

7-4. HTTPメソッドとステータスコードの関係

HTTPメソッドは「何をしたいか」を示すものですが、その操作が「どうなったか」を示すのがHTTPステータスコードです。メソッドとステータスコードは組み合わせて理解することが重要です。

GETリクエストに対する 200 OK は「取得成功」を意味します。
POSTリクエストに対する 201 Created は「新規作成成功」を意味します。
PUTリクエストに対する 200 OK や 204 No Content は「更新成功」を意味します。
DELETEリクエストに対する 200 OK や 204 No Content は「削除成功」を意味します。
どのメソッドに対しても 404 Not Found が返される場合は、指定したURIのリソースが見つからなかったことを意味します。

適切なステータスコードを返すことは、APIの利用者にとって操作結果を正確に把握するために不可欠です。

7-5. ブラウザが主に使うメソッド

私たちが普段Webサイトを閲覧する際に、ブラウザが自動的に発行するHTTPメソッドは、主にGETとPOSTです。

アドレスバーへのURL入力、リンククリック、画像の表示などはGET。
<form method="post"> で指定されたフォームの送信はPOST。

PUTやDELETE、PATCHといったメソッドは、通常のHTMLの機能だけでは発行できません。これらを使用するには、JavaScript（Ajax/Fetch APIなど）を使ったり、専用のクライアントツールを使ったりする必要があります。そのため、これらのメソッドは主にWeb APIとの連携で使用されます。

8. まとめ：HTTPメソッドはWebコミュニケーションの基本

この記事では、HTTPメソッド、特にGET、POST、PUT、DELETEを中心に、その役割、使い方、そしてWebにおける重要性について詳しく解説しました。

HTTPメソッドは、クライアントがサーバー上のリソースに対して行いたい操作の種類（取得、作成、更新、削除など）を伝えるための「命令」です。
GETは取得、POSTはデータの送信（主に作成や処理）、PUTは指定URIの完全更新/作成、DELETEは削除、PATCHは部分更新、HEADはヘッダー取得、OPTIONSは利用可能メソッドの確認といった、それぞれの役割を理解することが重要です。
安全（Safe）なメソッドはサーバーの状態を変えません（GET, HEAD, OPTIONS）。
べき等（Idempotent）なメソッドは繰り返し実行してもリソースの最終状態が変わりません（GET, HEAD, PUT, DELETE, OPTIONS, TRACE）。
これらの特性を理解し、操作内容に応じてメソッドを適切に使い分けることで、WebシステムやWeb APIの設計が整理され、信頼性や効率が向上します。特にRESTful APIでは、このメソッドの使い分けが設計の基本となります。
データ送信においては、セキュリティ、データ量、キャッシュなどの観点から、GETとPOSTを正しく使い分けることが不可欠です。機密情報や大量のデータ送信、サーバーの状態を変更する操作にはPOSTを使用しましょう。

HTTPメソッドは、Webブラウザとサーバーがコミュニケーションするための基本的な「言葉」です。これらの言葉の意味を理解することは、Webがどのように動いているのかを知る上で非常に重要な一歩となります。

今回の内容が、皆さんがWeb開発やAPI連携について学ぶ上で、少しでもお役に立てれば幸いです。最初は難しく感じるかもしれませんが、実際にWebサイトを操作したり、簡単なAPIを使ってみたりしながら触れていくうちに、自然と理解が深まっていくはずです。

Webの世界は奥が深いですが、一つずつ基礎を固めていけば、きっと面白い発見がたくさんあるはずです。これからも、Webの世界の探求を楽しんでください！