#はじめに

「APIにPOSTしたのにデータが届かない」——調べてみると、Content-Typeヘッダーが抜けていた。こんな経験はありませんか？

HTTPヘッダーは、リクエストやレスポンスに「追加情報」を付与するための仕組みです。認証情報、データ形式、キャッシュ設定など、通信に必要な様々な情報がヘッダーに含まれています。

この記事を読むと、以下のことができるようになります：

  • 実務でよく使うHTTPヘッダーの役割を理解できる
  • APIリクエストを正しく構築できる
  • レスポンスヘッダーから必要な情報を読み取れる

#HTTPヘッダーとは

HTTPヘッダーとは、リクエストやレスポンスに付加情報を添えるための「キー: 値」形式のデータです。

手紙で例えると、封筒に書かれた「速達」「親展」「書留」といった注意書きのようなものです。中身（ボディ）とは別に、配達方法や取り扱い方法を指示しています。

Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

ヘッダーは複数指定でき、1行に1つのヘッダーを記述します。

#ヘッダーの分類

HTTPヘッダーは、用途によって大きく4つに分類できます。

分類説明例
リクエストヘッダークライアントからサーバーへの追加情報Accept, Authorization
レスポンスヘッダーサーバーからクライアントへの追加情報Set-Cookie, Location
表現ヘッダーボディの形式や言語に関する情報Content-Type, Content-Length
ペイロードヘッダー転送されるデータに関する情報Content-Encoding

実務では分類を意識することは少ないですが、「リクエスト時に使うもの」「レスポンスで返ってくるもの」の区別は重要です。

#リクエストでよく使うヘッダー

#Host

リクエスト先のホスト名（ドメイン）を指定します。HTTP/1.1では必須のヘッダーです。

Host: api.example.com

1つのIPアドレスで複数のドメインをホスティングしている場合、このヘッダーでどのサイト宛てかを判別します。

#Content-Type

送信するデータの形式（MIMEタイプ）を指定します。POSTやPUTでボディを送る際に必須です。

Content-Type: application/json

よく使うContent-Type：

値用途
application/jsonJSON形式のデータ
application/x-www-form-urlencodedHTMLフォームのデフォルト形式
multipart/form-dataファイルアップロード
text/plainプレーンテキスト

#Accept

クライアントが受け取りたいレスポンスの形式を指定します。

Accept: application/json

サーバーはこのヘッダーを参考に、適切な形式でレスポンスを返します。

#Authorization

認証情報を送信します。APIでトークン認証を使う場合に必須です。

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

認証スキーム（BearerやBasicなど）とクレデンシャルをスペースで区切って指定します。

スキーム形式用途
BearerBearer {token}JWT等のトークン認証
BasicBasic {base64(user:pass)}ユーザー名とパスワード

#User-Agent

クライアントの種類やバージョンを伝えます。

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36

ブラウザが自動的に設定しますが、APIクライアントやボットを識別するために使われることもあります。

保存されたCookieをサーバーに送信します。

Cookie: session_id=abc123; theme=dark

セッション管理やユーザー設定の保持に使われます。詳しくは後のモジュールで学習します。

#Origin

リクエスト元のオリジン（スキーム + ホスト + ポート）を示します。

Origin: https://example.com

CORS（Cross-Origin Resource Sharing）で、クロスオリジンリクエストの検証に使われます。

#レスポンスでよく見るヘッダー

#Content-Type

レスポンスボディの形式を示します。リクエストのContent-Typeと同じ役割です。

Content-Type: application/json; charset=utf-8

charsetパラメータで文字エンコーディングを指定することもあります。

#Content-Length

レスポンスボディのサイズ（バイト数）を示します。

Content-Length: 1234

クライアントにCookieを保存させる指示です。

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict

属性（HttpOnly、Secureなど）でCookieの挙動を制御します。詳しくは後のモジュールで学習します。

#Location

リダイレクト先のURLを示します。3xx レスポンスと一緒に返されます。

HTTP/1.1 302 Found
Location: https://example.com/dashboard

#Cache-Control

キャッシュの動作を制御します。

Cache-Control: max-age=3600, public

「1時間キャッシュしてよい」「誰でもキャッシュしてよい」などの指示を出します。詳しくはキャッシュ戦略モジュールで学習します。

#Access-Control-Allow-Origin

CORSで、どのオリジンからのリクエストを許可するかを示します。

Access-Control-Allow-Origin: https://example.com

詳しくはセキュリティモジュールで学習します。

#実践: DevToolsでヘッダーを確認する

実際にリクエストとレスポンスのヘッダーを確認してみましょう。

#手順

  1. DevToolsのNetworkタブを開く
  2. 任意のリクエストをクリック
  3. 「Headers」タブを選択
  4. 以下のセクションを確認：
    • General: URL、メソッド、ステータスコード
    • Response Headers: サーバーからのヘッダー
    • Request Headers: ブラウザが送信したヘッダー

#確認ポイント

  • Content-Type: 期待した形式でデータが送受信されているか？
  • Authorization: 認証トークンが正しく送信されているか？
  • Set-Cookie: サーバーがCookieを発行しているか？
  • Cache-Control: キャッシュ設定はどうなっているか？

#カスタムヘッダー

アプリケーション独自のヘッダーを使用することもできます。慣例としてX-プレフィックスが使われてきましたが、現在は非推奨です。

# 古い慣例（非推奨）
X-Request-ID: abc123

# 現在の推奨
Request-ID: abc123

ただし、既存のAPIではX-プレフィックスが使われていることも多いです。

#ヘッダーのサイズ制限

HTTPヘッダーにはサイズ制限があります。制限はサーバーによって異なりますが、一般的な目安：

  • 1つのヘッダー: 8KB〜16KB
  • ヘッダー全体: 16KB〜32KB

大量のデータをヘッダーで送ることは避け、必要に応じてボディを使用してください。

#まとめ

  • HTTPヘッダーは「キー: 値」形式で追加情報を伝える
  • リクエストでよく使うヘッダー:
    • Content-Type: 送信データの形式
    • Accept: 受け取りたいデータの形式
    • Authorization: 認証情報
  • レスポンスでよく見るヘッダー:
    • Content-Type: 返されたデータの形式
    • Set-Cookie: Cookieの発行
    • Location: リダイレクト先
    • Cache-Control: キャッシュ設定
  • DevToolsのHeaders タブで確認できる

#次のステップ

HTTPヘッダーの基本がわかったところで、次はHTTPSとTLSについて学びましょう。「なぜHTTPSが必要なのか」「証明書とは何か」——安全な通信の仕組みを理解することで、Webセキュリティの基礎が身につきます。

#参考リンク