皆さん、こんにちは！世界中を駆け巡るパケットの鼓動を感じながら、今日もWebの奥深い世界へと皆さんをご案内する、ネットワークアーキテクトの〇〇です。

私たちが普段何気なく利用しているWebサイトやアプリケーション。その裏側では、まるで人間同士がおしゃべりをするように、たくさんの情報が行き交っています。その「おしゃべり」のルールを決めているのが「HTTPプロトコル」というものです。

今回は、HTTPプロトコルの中でも、特に「Webサーバーから『やった！うまくいったよ！』というお返事が来たとき」に注目してみましょう。そう、「2xx (Successful)」というステータスコードの世界です。

「成功」と一言で言っても、実は色々な「成功」の形があるんです。郵便配達に例えながら、それぞれの「成功」がどんな意味を持つのか、一つずつ丁寧に紐解いていきましょう！

—

Webのおしゃべり：リクエストとレスポンス

まずは、HTTPのおしゃべりがどんな流れなのか、簡単に思い出してみましょう。

皆さんがWebブラウザでURLを入力したり、ボタンをクリックしたりすると、それはまるで「郵便局に行って、誰かに手紙（リクエスト）を出す」ようなものです。

この手紙は「Webサーバー」という、たくさんの情報を持っている賢い相手に届けられます。

サーバーは手紙を受け取ると、その内容を読み解き、「お返事（レスポンス）」を皆さんのWebブラウザに送り返してくれます。このお返事には、皆さんが見たいWebページの情報だったり、APIから取得したデータだったりが含まれています。

そして、このお返事には、必ず「スタンプ」のようなものが押されています。これが「HTTPステータスコード」です。このスタンプを見るだけで、「あ、今回の手紙のやり取りはうまくいったな」「あれ？何か問題があったのかな？」といった、おしゃべりの結果が一目でわかるようになっているんです。

私たちが今回注目するのは、このスタンプの中でも「2xx」という数字から始まるものです。これは「サーバーがリクエストを無事に受け取って、処理が成功したよ！」という、いわば「成功の証」なんです。

でも、「成功」と言っても、その内容は一つじゃありません。まるで「荷物、無事届きました！」「新しい商品作っときました！」「注文は受け付けたけど、まだ発送はしてないよ！」といった具合に、様々なニュアンスがあるんですよ。

さあ、それでは具体的な2xxコードを深掘りしていきましょう！

—

2xx (Successful) の世界：成功の裏側に隠されたメッセージ

「成功したよ！」というメッセージを伝える2xx系のステータスコード。ここからは、それぞれのコードがどんな「成功」を意味しているのか、具体例を交えながら見ていきましょう。

200 OK: 「無事にお届けできました！ご依頼の品はこちらです！」

これが2xxコードの中で最もポピュラーで、皆さんが一番よく目にする「成功」の形です。
まるで「郵便局に依頼された荷物を、問題なくお届けしました！はい、これがその荷物ですよ！」というようなイメージですね。

• 意味: クライアントのリクエストが正常に処理され、サーバーは要求されたリリソース（Webページ、画像、APIデータなど）をレスポンスボディに含めて返しています。
• クライアントの処理: レスポンスボディの内容をそのまま表示したり、データとして利用したりします。Webブラウザであれば、受け取ったHTMLを解析して画面に表示します。
• いつ使う？: Webページの表示、APIからのデータ取得、ファイルのダウンロードなど、クライアントが「何かちょうだい！」とリクエストして、サーバーが「はい、どうぞ！」とデータと共に返す、ほとんどの成功パターンで使われます。

サンプル：Webページを取得する例

クライアント（あなた）がWebサーバーに「index.htmlちょうだい！」とお願いするイメージ
curl -v “https://example.com/index.html”

Webサーバーからの返事（レスポンス）
< HTTP/1.1 200 OK # ✨ 200 OK！成功のスタンプが押されました！ < Date: Mon, 01 Jan 2024 12:00:00 GMT < Content-Type: text/html; charset=UTF-8 # 返されるデータの種類はHTMLだよ、と教えてくれます < Content-Length: 1234 # 返されるデータのサイズだよ、と教えてくれます < ここからレスポンスボディ（Webページの内容）が始まります

ようこそ！

このページは正常に表示されました。

201 Created: 「新しいものを作ってあげましたよ！」

これは「新しい郵便物を受け取って、その内容に基づいて、新しい何か（商品やサービスなど）を作り上げました！」というイメージです。そして、「作ったものはこれですよ！」と、その新しいものの情報も一緒に教えてくれます。

• 意味: クライアントのリクエスト（主にPOSTメソッド）によって、サーバー上で新しいリソースが正常に作成されたことを示します。
• クライアントの処理: レスポンスボディには通常、作成されたリソースの識別子（ID）や、そのリソースへアクセスするためのURL（Locationヘッダー）が含まれます。クライアントはこれを受け取って、次の処理に進んだり、作成されたリソースのページへリダイレクトしたりします。
• いつ使う？: ユーザー登録、記事の投稿、商品の追加など、データベースに新しいデータを保存するような処理でよく使われます。

サンプル：新しいユーザーを登録する例

クライアントがWebサーバーに「新しいユーザーを登録して！」とお願いするイメージ
curl -v -X POST \
-H “Content-Type: application/json” \
-d ‘{“username”: “newuser”, “email”: “newuser@example.com”}’ \
“https://api.example.com/users”

Webサーバーからの返事
< HTTP/1.1 201 Created # ✨ 201 Created！新しいものが作られました！ < Date: Mon, 01 Jan 2024 12:00:00 GMT < Content-Type: application/json # 返されるデータの種類はJSONだよ、と教えてくれます < Content-Length: 50 < Location: https://api.example.com/users/123 # 作成されたユーザーの情報はここにあるよ！ < ここからレスポンスボディ（作成されたユーザーの情報）が始まります { "id": 123, "username": "newuser", "message": "User created successfully." }

202 Accepted: 「受け付けました！でも、まだ処理は終わってないよ！」

これは「郵便物を受け取りました！これから処理を開始しますね。でも、まだ全部終わったわけじゃないから、ちょっと待っててね！」というニュアンスです。すぐに結果が出ない、時間のかかる処理の開始を伝えるときに使われます。

• 意味: サーバーがリクエストを正常に受け付けましたが、そのリクエストに対する処理がまだ完了していないことを示します。処理はバックグラウンドで非同期的に実行されることが前提です。
• クライアントの処理: クライアントは、処理が完了するのを待つか、後で処理状況を問い合わせるための別のリクエストを送信する必要があります。レスポンスボディには、処理状況を確認するためのURLや、現在のステータスに関する情報が含まれることがあります。
• いつ使う？: 大容量ファイルのアップロード（サーバー側での変換処理が必要な場合）、動画のエンコード、複雑なバッチ処理の開始など、すぐに結果を返せないようなケースで非常に役立ちます。

サンプル：重たいファイルをアップロードし、サーバー側で処理を開始する例

クライアントがWebサーバーに「このファイルをアップロードして処理を開始して！」とお願いするイメージ
curl -v -X POST \
-H “Content-Type: application/octet-stream” \
–data-binary “@large_file.zip” \
“https://api.example.com/uploads”

Webサーバーからの返事
< HTTP/1.1 202 Accepted # ✨ 202 Accepted！リクエストは受け付けたけど、まだ処理中だよ！ < Date: Mon, 01 Jan 2024 12:00:00 GMT < Content-Type: application/json < Content-Length: 78 < ここからレスポンスボディ（処理状況を確認するための情報）が始まります { "status": "processing", "job_id": "abc-123-xyz", "check_status_url": "https://api.example.com/uploads/abc-123-xyz/status" } クライアントはこの `check_status_url` を定期的に確認して、処理が完了したかどうかをチェックすることができます。

203 Non-Authoritative Information: 「ちょっと情報が古いかも？」

これは少し特殊なケースで、「郵便局は荷物を届けたんだけど、その荷物の差出人（オリジナルのWebサーバー）から直接受け取ったものじゃなくて、途中の代理店（プロキシサーバー）が持ってたコピーを渡したよ。だから、もしかしたらちょっと古い情報かもしれないよ？」というイメージです。

• 意味: オリジナルのサーバーではなく、プロキシサーバーがキャッシュからレスポンスを返した場合に使われます。本来のレスポンスは200 OKだったはずですが、プロキシが内容を変更して返している可能性があります。
• クライアントの処理: 基本的には200 OKと同じようにレスポンスボディの内容を利用しますが、情報の鮮度については注意が必要です。
• いつ使う？: CDN（コンテンツデリバリーネットワーク）のようなプロキシサーバーを経由してコンテンツが配信される場合に、ごく稀に見ることがあります。現代ではあまり積極的には使われないコードですが、その意味を知っておくと、ネットワークの仕組みをより深く理解できますよ。

204 No Content: 「成功したけど、返すものはないんです！」

これは「あなたの依頼は無事に完了しました！でも、特にあなたに返す『荷物』はないんですよ。現状維持でお願いしますね！」というイメージです。

• 意味: サーバーがリクエストを正常に処理しましたが、レスポンスボディに含めるコンテンツがないことを示します。つまり、「処理は成功したけど、何か表示するデータはないよ」という状態です。
• クライアントの処理: クライアントは、現在の画面をそのままにしたり、リクエストが送信されたフォームをクリアしたりするなどの処理を行います。画面遷移はしません。
• いつ使う？: フォームの入力内容を保存した時（成功したけど、特に「保存完了」のメッセージを表示するだけで画面はそのままにしたい場合）、データベースからデータを削除した時（「削除しました」という情報だけで、削除されたデータ自体を返す必要はないため）など、結果としてデータは返さないけれど、処理は成功したという状況で利用されます。

サンプル：記事を削除する例

クライアントがWebサーバーに「この記事を削除して！」とお願いするイメージ
curl -v -X DELETE “https://api.example.com/articles/456”

Webサーバーからの返事
< HTTP/1.1 204 No Content # ✨ 204 No Content！削除は成功したけど、返すデータはないよ！ < Date: Mon, 01 Jan 2024 12:00:00 GMT < レスポンスボディは空です

205 Reset Content: 「成功！画面をリセットしてください！」

204 No Contentと似ていますが、こちらは「あなたの依頼は無事に完了しました！特に返す『荷物』はないんだけど、もしフォームに入力してたら、その内容を全部リセットして、まっさらな状態に戻してあげてね！」という、より具体的な指示を含んでいます。

• 意味: サーバーがリクエストを正常に処理し、クライアント（特にフォーム）に対して、リクエストを送信したドキュメントビュー（画面）をリセットする（例えば、フォームの入力フィールドをクリアする）ように指示します。
• クライアントの処理: 通常、ブラウザはフォームの入力内容をクリアし、ドキュメントの初期状態に戻します。
• いつ使う？: アンケートフォームを送信した後、「ありがとうございました！」と表示しつつ、次の回答のためにフォームを空にしたい場合などに使われることがあります。

サンプル：フォーム送信後に画面をリセットする例

クライアントがWebサーバーに「アンケートを送信するよ！」とお願いするイメージ
curl -v -X POST \
-H “Content-Type: application/x-www-form-urlencoded” \
-d “question1=yes&question2=maybe” \
“https://example.com/survey”

Webサーバーからの返事
< HTTP/1.1 205 Reset Content # ✨ 205 Reset Content！成功したから、フォームをリセットしてね！ < Date: Mon, 01 Jan 2024 12:00:00 GMT < レスポンスボディは空です

206 Partial Content: 「データの一部だけお届けします！」

これは「あなたからの依頼で、大きな荷物の一部だけを切り取ってお届けしました！」というイメージです。特に、動画の再生や大きなファイルのダウンロードで、途中の部分から再開したい時などに非常に便利です。

• 意味: クライアントがRangeヘッダーを使ってリソースの一部だけを要求し、サーバーがその要求に応えてリソースの一部を返したことを示します。
• クライアントの処理: クライアントは、受け取ったデータ（通常はバイナリデータ）を既存のファイルに追加したり、動画の特定の再生位置から表示を開始したりします。
• いつ使う？: 動画ストリーミングサービスで、ユーザーが動画の途中の位置から再生を開始した場合や、ダウンロードが中断されたファイルを途中から再開する場合などに利用されます。

サンプル：動画ファイルの一部を取得する例

クライアントがWebサーバーに「この動画ファイルの1000バイト目から2000バイト目までちょうだい！」とお願いするイメージ
curl -v -H “Range: bytes=1000-2000” “https://example.com/video.mp4”

Webサーバーからの返事
< HTTP/1.1 206 Partial Content # ✨ 206 Partial Content！データの一部を返したよ！ < Date: Mon, 01 Jan 2024 12:00:00 GMT < Content-Type: video/mp4 < Content-Range: bytes 1000-2000/1234567 # このレスポンスに含まれるデータの範囲と、全体のサイズを教えてくれます < Content-Length: 1001 # 返されるデータのサイズ（2000-1000+1 = 1001バイト） < ここからレスポンスボディ（動画ファイルの一部データ）が始まります (バイナリデータなので、ここでは表示できませんが、動画の一部が流れてきます) ---

2xxステータスコードの使い分けが大切な理由

いかがでしたでしょうか？「成功」と一口に言っても、こんなにも様々なニュアンスがあるんですね。

これらの2xxステータスコードを適切に使い分けることは、WebアプリケーションやAPIを開発する上で非常に重要です。

• クライアントが賢く動ける: サーバーからの「成功」のメッセージが具体的であればあるほど、Webブラウザやアプリケーションは「次に何をすべきか」を判断しやすくなります。
• デバッグが楽になる: もし何か問題が起きた時に、「このエラーはサーバーがファイルを削除しようとしたけど、データがなかったから204を返したんだな」というように、何が起きたのかを正確に把握しやすくなります。
• APIの品質向上: 開発者がAPIを設計する際、適切なステータスコードを返すことで、そのAPIの使いやすさや信頼性が大きく向上します。

まるで、郵便局からの返事に「荷物届いたよ」「新しいサービス作ったよ」「注文は受け付けたけどまだ届かないよ」といった具体的なスタンプが押されている方が、受け取った側も安心できますし、次に取るべき行動が明確になりますよね。

—

まとめ

今回はHTTP/1.1の2xxステータスコード、つまり「成功」を表す様々なコードについて深掘りしてきました。

• 200 OK: 最も基本的。リクエストした内容をデータと共に返す。
• 201 Created: 新しいリソースをサーバー上に作成したことを通知。作成されたリソースの情報を返す。
• 202 Accepted: リクエストは受け付けたが、処理は非同期で継続中。すぐに結果は返さない。
• 204 No Content: 処理は成功したが、返すデータは特にない。画面は現状維持。
• 205 Reset Content: 処理は成功したが、クライアントのフォームなどをリセットするよう指示。
• 206 Partial Content: リクエストされたデータの一部だけを返す。

これらのコード一つ一つが、Webサーバーとクライアントの間で交わされる「おしゃべり」の、大切なメッセージなんですね。

「Webの仕組みって、なんだか複雑で難しそう…」と感じていた方も、こうして一つずつ紐解いていくと、意外と身近な出来事に例えられたり、人間同士のコミュニケーションのように感じられたりしませんか？

HTTPステータスコードは、Webの世界の「共通言語」です。この言葉を理解することで、皆さんがWebの動きをより深く理解し、トラブルシューティングや開発に役立てられることを願っています。

これからも一緒に、Webの世界を冒険していきましょう！それでは、また次の記事でお会いしましょう！