HTTP／リクエスト・レスポンス・ステータスコードの基本
1. はじめに
「APIを叩く」「404エラーが出た」「ステータスコード200が返ってきた」——Web開発に携わっていると当たり前のように使う言葉ですが、その土台にあるHTTPの仕組みを改めて説明できるでしょうか。
本記事では、Webの通信を支えるHTTPについて、リクエストとレスポンスの構造、代表的なステータスコード、そして実務でつまずきやすいポイントを初心者向けに解説します。
2. HTTPとは何か
HTTP(HyperText Transfer Protocol)は、Webブラウザとサーバーが情報をやり取りするための通信ルール(プロトコル)です。私たちが普段、ブラウザにURLを入力してWebページを表示したり、アプリがサーバーからデータを取得したりする際、裏側では必ずこのHTTPの仕組みが使われています。
HTTP通信の基本的な流れは、次のようにとてもシンプルです。
1.クライアント(ブラウザやアプリ)がサーバーに対して「これをください」というリクエストを送る
2.サーバーがリクエストを処理し、「これが結果です」というレスポンスを返す
このリクエストとレスポンスの1往復を基本単位として、Web上のあらゆる通信が成り立っています。
3. リクエストの構造
クライアントがサーバーに送るリクエストは、主に以下の要素で構成されています。
1. メソッド(HTTPメソッド)
「何をしたいか」を表す動詞のようなものです。代表的なメソッドは以下の通りです。
| メソッド | 意味 | 使用例 |
|---|---|---|
| GET | データを取得する | 商品一覧を表示する |
| POST | データを新規作成する | 会員登録、注文の作成 |
| PUT | データを丸ごと更新する | ユーザー情報を全項目更新する |
| PATCH | データを部分的に更新する | ユーザーのメールアドレスだけ更新する |
| DELETE | データを削除する | カート内商品の削除 |
GETは「見るだけ」の操作、POST/PUT/PATCH/DELETEは「サーバー側のデータを変化させる」操作、とざっくり理解しておくと全体像がつかみやすくなります。
2. URL(エンドポイント)
「どこに対して」リクエストするかを表します。例えば以下のようなURLです。
https://api.example.com/products/123この場合、「idが123の商品」に対するリクエストであることを表しています。
3. ヘッダー(Header)
リクエストに付随する追加情報です。認証情報や、送信するデータの形式などを伝えます。
Content-Type はリクエストボディの形式(JSON形式であることなど)、Authorization は認証トークンをサーバーに伝えるためのヘッダーです。
4. ボディ(Body)
POSTやPUTなど、データを送信する際に使う本体部分です。GETリクエストでは基本的に使いません。
4. レスポンスの構造
サーバーから返ってくるレスポンスも、同様にいくつかの要素で構成されています。
1. ステータスコード
リクエストの処理結果を3桁の数字で表します。詳細は後述します。
2. ヘッダー
レスポンスにもヘッダーが付与されます。返却するデータの形式(Content-Type)や、キャッシュに関する指示(Cache-Control)などが含まれます。
3. ボディ
実際に返されるデータ本体です。Web APIの場合、多くはJSON形式で返されます。
5. ステータスコードの基本
ステータスコードは先頭の数字によって、大きく5つのグループに分類されます。
| 分類 | 意味 |
|---|---|
| 1xx | 情報:処理継続中(実務で意識する機会は少ない) |
| 2xx | 成功:リクエストが正常に処理された |
| 3xx | リダイレクト:別の場所への転送が必要 |
| 4xx | クライアントエラー:リクエスト側に問題がある |
| 5xx | サーバーエラー:サーバー側に問題がある |
よく使う2xx系(成功)
200 OK:リクエストが正常に処理された、最も基本的な成功レスポンス
・201 Created:新しいリソースが正常に作成された(POSTでの登録処理など)
・204 No Content:処理は成功したが、返す内容がない(削除処理の完了など)
よく使う3xx系(リダイレクト)
・301 Moved Permanently:リソースが恒久的に別のURLへ移動したことを示す(URL変更時など)
・302 Found:一時的に別のURLへリダイレクトする
よく使う4xx系(クライアントエラー)
・400 Bad Request:リクエストの形式が不正(必須項目の欠落、JSONの構文エラーなど)
・401 Unauthorized:認証が必要、または認証情報が無効(ログインしていない状態など)
・403 Forbidden:認証はされているが、そのリソースへのアクセス権限がない
・404 Not Found:指定されたリソースが存在しない
・429 Too Many Requests:短時間に大量のリクエストを送りすぎている(レート制限)
・401と403は混同しやすいポイントです。401は「あなたが誰かわからない(未ログイン、トークン切れなど)」、403は「あなたが誰かはわかるが、その操作をする権限がない」という違いがあります。
よく使う5xx系(サーバーエラー)
・500 Internal Server Error:サーバー内部で予期しないエラーが発生した(アプリケーションのバグなど)
・502 Bad Gateway:サーバーの手前にあるプロキシやロードバランサーが、後続サーバーから不正な応答を受け取った
・503 Service Unavailable:サーバーが一時的に処理できない状態(メンテナンス中、過負荷状態など)
4xxは「リクエストを送った側(クライアント)に原因がある」、5xxは「受け取った側(サーバー)に原因がある」という切り分けを覚えておくと、障害調査の初動が速くなります。
6. 実際の通信を確認してみる
普段何気なく開いているWebページも、ブラウザの開発者ツールを使えば実際のHTTP通信を確認できます。Chromeであれば F12 キー(またはメニューから「その他のツール」→「デベロッパーツール」)で開発者ツールを開き、「Network」タブを選択した状態でページを再読み込みすると、発生した全てのリクエスト・レスポンスの一覧が表示されます。
各行をクリックすると、以下の情報が確認できます。
・リクエストURL・メソッド
・ステータスコード
・リクエストヘッダー・レスポンスヘッダー
・レスポンスボディの中身
エラーが発生した際、まずこの画面で「どのリクエストが」「何番のステータスコードで」失敗しているかを確認するのが、Web開発におけるトラブルシューティングの基本動作です。
7. HTTPとHTTPSの違い
「HTTPS」はHTTPに暗号化の仕組み(TLS/SSL)を追加したものです。通信内容が暗号化されるため、第三者による盗聴や改ざんを防げます。現在ではほぼすべてのWebサイトがHTTPSを採用しており、ブラウザによっては非HTTPS(平文HTTP)のサイトに対して「保護されていない通信」といった警告を表示します。
URLの先頭が https:// であれば暗号化された通信、http:// であれば暗号化されていない通信、とまず覚えておけば十分です。
8. まとめ
HTTPは、WebサイトやWeb APIを利用する上で欠かせない通信の仕組みです。一見すると単純なリクエストとレスポンスのやり取りですが、その中にはデータの受け渡し方法や認証、エラー通知など、Webシステムを支えるさまざまなルールが含まれています。
HTTPの基本を理解しておくことで、API開発やフロントエンド開発はもちろん、障害発生時の原因調査やパフォーマンス改善など、さまざまな場面で役立ちます。特にステータスコードやリクエスト・レスポンスの構造を理解していると、エラーの原因を素早く切り分けられるようになり、開発や運用の効率も大きく向上します。
