# HTTPメソッド

HTTPメソッドは、HTTPリクエストにおいてサーバーに対してどのような操作を要求するかを示すためのものです。
代表的なHTTPメソッドには、以下のようなものがあります。

- GET: リソースの取得
- POST: リソースの作成
- PUT: リソースの更新
- DELETE: リソースの削除
- CONNECT: 接続を保持する(トンネル構築)

これらのメソッドは、RESTful APIの設計においても重要な役割を果たします。

ここではそれぞれのメソッドについて少しだけ詳しくみていきます。

## リクエストとレスポンス

HTTPでは、リクエスト(request; 要求)とレスポンス(response; 応答)の1往復が基本となっています(一期一会)。
そのため、接続したら『何をしたいか+必要となるデータ』を**リクエスト**として送信します。
その後、サーバーはそのリクエストに対する**レスポンス**を返します。

リクエストもレスポンスもそれぞれ『ヘッダ』と『ボディ』という部分に分かれており、境目は空行となっています。

```{mermaid}
sequenceDiagram
    participant Client as ブラウザ
    participant Server as Webサーバー
    Client->>Server: リクエストヘッダ
    Client-->>Server: 空行
    Client-->>Server: リクエストボディ(最後に空行を入れてリクエスト終了)
    Server-->>Client: ステータスとレスポンスヘッダ
    Server-->>Client: 空行
    Server-->>Client: レスポンスボディ
```

HTTP(2以前)はこのやりとりがテキストベースで行われており、その気になれば**手入力でリクエストが送れる**というシンプルさもありました。

## GETメソッド

GETメソッドは、指定したリソースの取得を行うためのメソッドです。主な特徴は以下の通りです。

ただし『本来は』という断り書きを付けておく方がいいかもしれません。
場合によっては以下のようにならないこともあるからです。

- 安全(Safe)
    リソースを変更せず、データ取得のみを行うため、サーバーの状態に影響を与えません。  
- 冪等(Idempotent)  
    同じリクエストを何度送っても結果が変わりません。  
- キャッシュ可能(Cacheable)  
    冪等であるということはレスポンスはキャッシュ可能となります。同じリクエストに対してはキャッシュされたデータが返されることがあります。

2000年位までのWebサーバーですと、多くのページが上記のものとなる静的なコンテンツであることが多い状況でした。
そのためプロキシサーバーが、キャッシュという形でブラウザに近いところで保持することが多く行われておりました。
ですが現在では、動的なコンテンツが増え、キャッシュされないことも多くなっています。

### 主なステータスコード

GETを含めて、メソッドによるリクエストを送信することで、その処理の可否等の情報は **ステータスコード** という形で数字(+文字列)で返却されます。
よくみるもとしては、以下のものがあるでしょう。

- 200 OK: 正常にリソースが返却された  
- 301 Moved Permanently: リソースが移動したため、リダイレクトされる
- 403 Forbidden: アクセスが禁止されている
- 404 Not Found: リソースが存在しない場合
- 500 Internal Server Error: サーバー内部でエラーが発生した場合
- 503 Service Unavailable: サーバーが一時的に利用できない場合

3桁の数字には一応のルールがあります。これを覚えておくだけでも状況の分類の役に立ちます。

|数値|意味|
|:----|:------|
|200番台|成功|
|300番台|リダイレクト|
|400番台|クライアントエラー(悪いのは利用者)|
|500番台|サーバーエラー(悪いのはサーバー側)|

## POSTメソッド

POSTメソッドはGET同様にコンテンツを返してもらうことが最終的な動きとなります。
ですが、名前の通りというべきか『**サーバーにデータを送信する**』ことが主目的になっています。
**送信したことによる結果としてどうなったか** がレスポンスであると考えてください。

## PUTメソッド

POSTと近い表現に思える **PUTメソッド** ですが、こちらは『指定したリソースを**完全に置き換える**』ことが主目的となっています。POSTは結果的に置き換えが起きるかもしれませんが、PUTはより積極的(というか必ず)に置き換えを行います。
置き換えができないときはエラーとなります。


## DELETEメソッド

**DELETEメソッド** は文字通りの削除です。リソースの削除を行うことが目的となっています。

## CONNECTメソッド

**CONNECTメソッド** は少し特殊です。
HTTP/1.1以降で正式に定義されたこのメソッドは、**接続そのもの**を確立することが目的となっています。
『HTTPの時点で繋がっているのでは』と思うかもしれませんが、プロトコル的に往復のやりとりが終了したら切れることが前提となっています。
CONNECTはそこを根底から覆します。往復の接続(より正確には非同期での送受信)を維持することを目的としており、いわばTCPのような感じになります。これにより、接続された回線上で任意のデータを送受信できるようになります。

用途的には、プロキシサーバーに繋ぐときや、HTTPS(暗号化接続)を使ったときの内部通信といったものが挙げられます。

## HTTPのバージョンについて

HTTPは、1991年に最初のバージョンとも言える0.9が登場しました。その後段階を経て進化をし続けているものとなっています。簡単に表にまとめると、以下のようになります。
基本的に上位バージョンをサポートするサーバーは、下位バージョンもサポートしているのがほとんどです(というより古いバージョンをサポートしていないというモノは見たことありません)。

| バージョン | 規格化された年月 | 主な特徴 |
|:---|:---:|:---|
| HTTP/0.9 | 1991(非公式・初期実装) | 単純なGETのみ、ヘッダ無し、プレーンテキスト応答 |
| HTTP/1.0 | 1996-05(RFC 1945) | リクエスト/レスポンスヘッダ導入、ステータスコード、接続は基本切断 |
| HTTP/1.1 | 1997-01(RFC 2068 ※) | キープアライブ(持続接続)、パイプライン、Hostヘッダ、キャッシュ制御の改良 |
| HTTP/2 | 2015-05(RFC 7540) | バイナリ化、ストリームのマルチプレクシング、ヘッダ圧縮(HPACK)、サーバープッシュ |
| HTTP/3 | 2022-06(RFC 9114) | QUIC(UDP上のトランスポート)採用、接続確立高速化、ヘッドオブラインブロッキング解消、QPACK |

※ 改訂: 1999-06 RFC 2616、整理: 2014-06 RFC 7230-7235 と進んでいます

歴史的には、随分と長く1.1が使われてきましたが、昨今では徐々にHTTP/2および3への移行が行われているようです。
特にHTTP/2は、パフォーマンスの向上を目的としており、複数のリクエストを同時に処理できるマルチプレクシングや、ヘッダ圧縮などの機能が追加されています。HTTP/3はさらに進化したもので、QUICという新しいトランスポートプロトコルを採用しています。

これらのバージョンは、HTTPによるリクエストの際にバージョンを通知することで、サーバーとクライアントがどのバージョンで通信するかを決定します。

たとえば以下は`curl`コマンドにおけるサーバー接続の冗長出力(`curl -v`)によるものです。
`>`部分がクライアント(`curl`)からサーバーへのリクエスト、`<`部分がサーバーからクライアントへのレスポンスとなっています。

```{code-block}
    :language: plain
    :emphasize-lines: 1,7

> GET / HTTP/2      <----- リクエスト時にHTTP/2を使うことを通知
> Host: www.google.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 200        <------ レスポンス側もHTTP/2で返却
< date: Mon, 01 Sep 2025 00:36:28 GMT
< expires: -1
< cache-control: private, max-age=0
< content-type: text/html; charset=ISO-8859-1
```

```{note}
## QUICプロトコル(概要)

QUICはUDP上で動作する新しいトランスポート層プロトコルで、主に低遅延での接続確立と信頼性の高いストリーム多重化を目的としています。TLS 1.3を統合しており、ほとんどの制御情報とペイロードを暗号化します。HTTP/3はQUIC上で動作するよう設計されています。

### 主な特徴
- UDPベース: 従来のTCPとは異なりUDPを使ってユーザー空間で再実装される。
- 多重ストリーム: 複数の論理ストリームを1つの接続で同時に扱い、トランスポート層でのヘッドオブラインブロッキングを回避。
- TLS 1.3統合: 接続の暗号化と認証をトランスポートに組み込み、0-RTT接続や高速なハンドシェイクを実現。
- 0-RTT/1-RTT: 再接続時の遅延低減(ただしリプレイ攻撃に対する注意が必要)。
- コネクションマイグレーション: クライアントのIPアドレス変更(モバイル環境など)時にも接続を維持可能。
- パケット番号やヘッダの暗号化: トラフィック解析の難易度を上げる。
- TCP互換のない設計: 一部の中間機器(ファイアウォール/プロキシ)との相互運用性に注意が必要。

### 利点と注意点
- 利点: 接続確立の高速化、ページロードの低遅延化、並列リソース取得の効率化、接続移行のサポート。
- 注意点: UDPフィルタリングされるネットワークや古い中間機器での問題、実装の複雑さ、0-RTTのセキュリティ考慮など。
    - NATとの相性という意味ではUDPを使うことにより『いつ確実に切断されたか』がわかりにくいという問題があります。そのためNATテーブルが枯渇しやすくなる恐れがあります。

### 参考(参照先)
- RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport  
    https://www.rfc-editor.org/rfc/rfc9000.html
- RFC 9001 — Using TLS to Secure QUIC  
    https://www.rfc-editor.org/rfc/rfc9001.html
- RFC 9002 — QUIC Loss Detection and Congestion Control  
    https://www.rfc-editor.org/rfc/rfc9002.html
- HTTP/3 (QUIC上で動作するHTTP) — RFC 9114  
    https://www.rfc-editor.org/rfc/rfc9114.html
- IETF QUIC Working Group — ドキュメントとドラフト一覧  
    https://datatracker.ietf.org/wg/quic/about/
- 参考解説記事(実装と概要)  
    https://www.chromium.org/quic (Google/Chromium の概要ページ)  
    https://blog.cloudflare.com/announcing-http3-quic/ (Cloudflare 技術ブログ)


```