HTTPはHTML専用じゃない話

正式名称は HyperText Transfer Protocol（ハイパーテキスト転送プロトコル）。「HTTPってハイパーテキストだからHTML専用でしょ？」と思われるかもしれませんが、現在のHTTPはHTMLに限らずJSONや画像などを運べます。ただし初期のHTTP/0.9と、ヘッダーを備えたHTTP/1.0以降は分けて理解しましょう。

HTMLから多様なデータへ

初期のHTTP/0.9は単純なGETでHTMLを返し、応答ヘッダーを持ちませんでした。HTTP/1.0ではステータス行やメディアタイプを示すヘッダーを備え、HTML以外も扱える仕組みが整っています。

設計のポイント

HTTP/1.0以降ではContent-Typeで本文の形式を示します。現在はtext/html、image/png、application/jsonなどが使われます。JSONが初期HTTPに存在したという意味ではありません。
メソッドとヘッダーで拡張しやすい構造。後からPOST/PUT/DELETEやCache-Controlなどが追加されても破綻しにくい。
正式名称は HyperText Transfer Protocol。「ハイパーテキスト」という言葉が強いだけで、中身はもっと懐深いです。
HTTPSはHTTP通信を暗号化・認証して運ぶ仕組みです。HTTP/1.1・2ではTLS、HTTP/3ではTLS 1.3を統合したQUICを使います。暗号化されても内容の正しさやサイトの信頼性まで保証されるわけではありません。

HTML以外、いまは当たり前

Web APIやファイル配信など、HTML以外を扱う用途もあります。APIの形式がすべてJSONに決まっているわけではありません。

よくある非HTMLコンテンツ

JSON / XML のWeb APIやWebhook（application/json, application/xml）。
ファイル配信（image/png, application/pdf, application/zip など）。
SSEはtext/event-streamのHTTP応答でイベントを配信します。WebSocketはHTTP/1.1のUpgradeなどで接続を確立した後、独自のフレームで通信する別のプロトコルです。
GraphQLやgRPC-webなど、HTTPをトランスポートにした別プロトコル風のやりとり。

柔軟に運べる仕掛け 🤝

汎用性を支えるのはヘッダーと交渉の仕組み。Content-Type/Acceptが仲介役です。

コンテンツネゴシエーション

クライアントはAcceptで欲しいメディアタイプを提示、サーバーはContent-Typeで実際に返すタイプを宣言。
言語やエンコードもAccept-Language / Accept-Encodingで交渉できる。
Acceptに合う表現を提供できなければ406を返すか、仕様上は希望を尊重せず利用可能な表現を返す場合もあります。クライアントは実際のContent-Typeを確認して処理します。

メソッドとボディの自由度

GET/HEADで取得、POSTで送信・作成、PUT/PATCH/DELETEで更新/削除と役割が分かれている。
本文を送れるかはメソッドや応答コードに従います。GETの要求本文に一般的な意味はなく、HEADの応答や204・304には本文を付けられません。Content-Typeを付ければ常に本文を送れるわけではありません。

実務のちょいコツ 💡

「とりあえずJSON返せばいいでしょ」から一歩進んで、HTTPらしいお作法を押さえるとトラブルが減ります。

ありがちな落とし穴

Content-Type未設定や誤設定でクライアントがパースに失敗する。
HTML前提のミドルウェアがAPIレスポンスを書き換える（例: フォームCSRFエラーでHTMLエラーページが混入）。
JSONを期待するクライアントにHTMLのエラーページを返すと、JSON解析に失敗します。成功時だけでなくエラー時のステータス・Content-Type・本文も確認しましょう。

ゆるまとめ

現在のHTTPは多様なデータを運びますが、メソッドや本文のルールは共通です。メソッドの使い分け、バージョンごとの違い、キャッシュの条件を組み合わせて理解しましょう。

< HTTPステータス 418 I'm a teapot とは？ HTTPリクエストメソッドの使い分け >