概要

HTTPヘッダーは通信条件や補足情報を伝える場所で、Content-Type はその中でも特に重要です。ヘッダーとボディ形式の関係を理解すると、APIの送受信、デバッグ、エラー切り分けがかなりやりやすくなります。

ヘッダーは何のためにあるか

ヘッダーは、本文そのものではなく「どう送るか」「どう受け取りたいか」「どんな条件で処理してほしいか」を伝えるための情報です。

HTTPメッセージには、開始行の後ろにヘッダーが並びます。ヘッダーには、次のような役割があります。

• 送信する本文の形式を伝える
• 受け取りたい形式を伝える
• 認証情報を渡す
• キャッシュの扱いを指定する
• Cookieを送受信する
• どのホスト向けの通信かを示す

ボディが「本体のデータ」、ヘッダーが「そのデータの取り扱い説明書」というイメージです。

ヘッダーを理解していないと、本文の内容が正しくてもAPIが失敗する理由を見落としやすくなります。

最初に押さえたい代表的なヘッダー

ヘッダーは数が多いですが、実務で頻出するものから覚えると十分です。特に Host、Accept、Content-Type、Authorization、Cookie は重要です。

リクエスト側でよく見るもの

API利用やフロントエンド開発では、リクエストヘッダーの理解が特に重要です。サーバーはヘッダーを見て処理方法を決めることがあります。

POST /products HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer xxxxxx
Content-Type: application/json

この例からは、次のことが読み取れます。

• Host: 送信先は api.example.com
• Accept: JSONで返してほしい
• Authorization: 認証が必要なAPI
• Content-Type: 送る本文はJSON形式

レスポンス側でよく見るもの

レスポンスヘッダーを見ると、返ってきたデータの形式や、ブラウザがどう扱うべきかがわかります。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Set-Cookie: session_id=abc123; HttpOnly; Secure

この例からは、次のことが読み取れます。

• Content-Type: 本文はJSON
• Cache-Control: no-store: キャッシュさせたくない
• Set-Cookie: ブラウザへセッションCookieを発行している

Content-Type は何を表すか

Content-Type は「このボディはどんな形式か」を示すヘッダーです。APIの送受信で最も重要なヘッダーの1つで、これがずれるとサーバーやクライアントが本文を正しく解釈できません。

Content-Type はリクエストにもレスポンスにも現れます。

• リクエストの Content-Type: クライアントが送る本文の形式を示す
• レスポンスの Content-Type: サーバーが返す本文の形式を示す

たとえばJSONを送る場合は、次のようになります。サーバーはこのヘッダーを見て、「本文はJSONとして解釈すべきだ」と判断します。

POST /products HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name":"Keyboard","price":5000}

Accept との違い

Content-Type は"実際に送るデータ形式"を示し、Accept は"受け取りたいデータ形式"を示します。両者は似ていますが、役割が違います。

次の例では、送る本文もJSONで、返ってくるレスポンスもJSONを期待しているという意味になります。

POST /products HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{"name":"Keyboard","price":5000}

Content-Type が重要な理由

本文の中身が正しくても、Content-Type が間違っているだけで失敗することがあります。実務では非常によくある原因です。

よくある失敗:

• JSONを送っているのに Content-Type を付けていない
• application/json のつもりが別形式になっている
• フォーム送信なのにJSONとして処理しようとしている

よく使うボディ形式

HTTPボディにはさまざまな形式がありますが、最初に押さえるべきなのはJSON、フォームURLエンコード、multipart/form-data、プレーンテキストです。

JSON

JSONは現代のWeb APIで最もよく使われる形式です。構造化データを扱いやすく、言語をまたいで利用しやすいのが利点です。

POST /products HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Keyboard",
  "price": 5000
}

オブジェクトや配列を表現でき、フロントエンド・バックエンド双方で扱いやすいのが特徴です。JSON構文が壊れていると解釈できないため、文字列の引用符やカンマ漏れに注意が必要です。

application/x-www-form-urlencoded

HTMLフォームの基本送信形式で、キーと値をURLクエリのような形で表現します。簡単な入力送信でよく使われます。

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

email=test@example.com&password=secret

単純なフォーム送信に向き、ブラウザの標準フォーム送信で使われやすいです。ネストした構造の表現には向きません。

multipart/form-data

ファイルアップロードを含むフォーム送信でよく使われる形式です。本文が複数パートに分かれ、テキストとファイルを一緒に送れます。

POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryExample

ファイルを送ることができ、テキスト項目とファイルを混在させられます。本文構造が複雑なため、手書きで組み立てるよりブラウザやライブラリに任せる方が安全です。

text/plain

構造化されていない単純な文字列を送る形式です。APIでは主流ではありませんが、簡易な疎通確認やWebhook検証で使われることがあります。

POST /echo HTTP/1.1
Host: example.com
Content-Type: text/plain

hello world

レスポンスの Content-Type も重要

レスポンス側の Content-Type は、クライアントが本文をどう解釈するかを決める重要な情報です。API利用時はレスポンスボディだけでなく、必ず Content-Type も確認します。

同じ 200 OK でも、本文の意味は Content-Type を見ないと正しく理解できません。

認証や状態管理に関わるヘッダー

ヘッダーはデータ形式だけでなく、認証やログイン状態の維持にも深く関わります。Authorization と Cookie / Set-Cookie は特に重要です。

Authorization

Authorization は認証情報を送るためのヘッダーです。APIではBearerトークン形式をよく見かけます。

GET /me HTTP/1.1
Host: api.example.com
Authorization: Bearer xxxxxx
Accept: application/json

JWTの送信、APIトークンの送信、OAuth 2.0 アクセストークンの送信などに使われます。ログ出力時にマスクが必要な点と、フロントエンドやリバースプロキシ設定で消えないか確認が必要な点に注意してください。

Cookie と Set-Cookie

ブラウザ中心のWebアプリでは、ログイン状態の維持にCookieがよく使われます。レスポンスで Set-Cookie を返し、次回以降のリクエストで Cookie として送ります。

レスポンス例:

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure

次回リクエスト例:

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=abc123

この流れを理解していないと、ログイン状態が維持されない問題の切り分けが難しくなります。

キャッシュや遷移に関わるヘッダー

すぐに全部を覚える必要はありませんが、Cache-Control と Location は実務でかなり役立ちます。

Cache-Control

キャッシュさせるかどうか、どれくらい保持してよいかを制御するヘッダーです。画面更新が反映されない問題でよく関係します。

Location

新規作成したリソースの場所や、リダイレクト先を示すヘッダーです。

HTTP/1.1 201 Created
Location: /products/101

DevToolsとcurlでどこを見るか

ヘッダーは暗記するより、実際の通信で確認する習慣を持つ方が重要です。まずは Headers、Payload、Response を対応づけて見るのが効果的です。

{{image:devtools_headers_view}}

ブラウザの開発者ツールでは、次の順で見ると整理しやすいです。

1. Request URL
2. Request Method
3. Status Code
4. Request Headers
5. Request Payload または Form Data
6. Response Headers
7. Response

curl でJSONを送る例:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"name":"Keyboard","price":5000}' \
  https://api.example.com/products

フォームURLエンコードの例:

curl -i \
  -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "email=test@example.com&password=secret" \
  https://example.com/login

よくあるつまずき

ヘッダーとボディ形式の不一致は、HTTP初学者だけでなく実務でも頻出します。問題が起きたら、本文だけでなくヘッダーも必ず見るのが基本です。

「本文は正しそうだから大丈夫」と考えてしまうことが初心者に多いですが、ヘッダーがずれているだけで正常に動かないことは珍しくありません。

まとめ

HTTPヘッダーは、本文の外側から通信の意味を補う重要な要素です。中でも Content-Type はボディ形式の理解に直結し、API実装とデバッグで最優先で押さえるべきヘッダーです。

• ヘッダーは通信条件、データ形式、認証、キャッシュなどを伝える
• Content-Type はボディの形式を示す
• Accept は受け取りたい形式を示し、Content-Type とは役割が違う
• JSON、フォームURLエンコード、multipart/form-data は特によく使う
• レスポンス側の Content-Type も本文解釈に重要
• Authorization、Cookie、Set-Cookie、Cache-Control、Location も実務で頻出する
• 不具合調査では本文だけでなく、必ずヘッダーを確認する