HTTPはHTML専用じゃない話

そもそも汎用プロトコルとして生まれた 🧭

初期HTTP/0.9〜1.0はシンプルなGET/レスポンス構造でしたが、中身はMIMEで何でもOKという設計でした。「HTML配送専用」ではなかったんですね、意外と。

設計のポイント

• Content-Typeで中身を宣言する前提。text/htmlだけでなくimage/pngやapplication/jsonなど何でも載せられる。
• メソッドとヘッダーで拡張しやすい構造。後からPOST/PUT/DELETEやCache-Controlなどが追加されても破綻しにくい。
• 正式名称は HyperText Transfer Protocol。「ハイパーテキスト」という言葉が強いだけで、中身はもっと懐深いです。
• HTTPSはHTTP + TLSのセット。転送中を暗号化し、証明書で相手を確認する仕組みがデフォルトになりました。

HTML以外、いまは当たり前

実務では非HTMLコンテンツが主役になる場面が多いです。「API＝HTTPでJSON」がデフォルトみたいな空気すらありますね。

よくある非HTMLコンテンツ

• JSON / XML のWeb APIやWebhook（application/json, application/xml）。
• ファイル配信（image/png, application/pdf, application/zip など）。
• ストリーミングやイベント配信（text/event-streamによるSSE、WebSocketへのUpgradeなど）。
• GraphQLやgRPC-webなど、HTTPをトランスポートにした別プロトコル風のやりとり。

柔軟に運べる仕掛け 🤝

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

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

• クライアントはAcceptで欲しいメディアタイプを提示、サーバーはContent-Typeで実際に返すタイプを宣言。
• 言語やエンコードもAccept-Language / Accept-Encodingで交渉できる。
• 「JSONがいいな」「いやHTML返すね」みたいな柔軟さがHTTPの醍醐味ですね。

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

• GET/HEADで取得、POSTで送信・作成、PUT/PATCH/DELETEで更新/削除と役割が分かれている。
• リクエストボディにもレスポンスボディにも任意のペイロードを積める（Content-Typeだけはちゃんと付ける）。

実務のちょいコツ 💡

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

おすすめの扱い方

• Content-Type/Acceptを正しく付ける。JSONならapplication/json、バイナリは適切なMIMEを選ぶ。
• ステータスコードは標準に沿って使う（200/201/204、4xx/5xx）。独自コードは避けるか意味を文書化。
• キャッシュ制御はCache-ControlとETagで。APIでもGETのレスポンスに付けると帯域が節約できる。
• エラーもJSONで返すなら形式を決めて統一（messageとcodeなど）。

ありがちな落とし穴

• Content-Type未設定や誤設定でクライアントがパースに失敗する。
• HTML前提のミドルウェアがAPIレスポンスを書き換える（例: フォームCSRFエラーでHTMLエラーページが混入）。
• JSONしか返さないのにAcceptを見ずに200/HTMLを返すと、意図せずブラウザでレンダリングされることも。うっかりですね。

ゆるまとめ

HTTPの名前に「ハイパーテキスト」とついているだけで、実は何でも運べる配達員。HTMLだけの人じゃないんですよ、という話でした。