

中嶋悟
名前:中嶋 悟(なかじま さとる) ニックネーム:サトルン 年齢:28歳 性別:男性 職業:会社員(IT系メーカー・マーケティング部門) 通勤場所:東京都千代田区・本社オフィス 通勤時間:片道約45分(電車+徒歩) 居住地:東京都杉並区・阿佐ヶ谷の1LDKマンション 出身地:神奈川県横浜市 身長:175cm 血液型:A型 誕生日:1997年5月12日 趣味:比較記事を書くこと、カメラ散歩、ガジェット収集、カフェ巡り、映画鑑賞(特に洋画)、料理(最近はスパイスカレー作りにハマり中) 性格:分析好き・好奇心旺盛・マイペース・几帳面だけど時々おおざっぱ・物事をとことん調べたくなるタイプ 1日(平日)のタイムスケジュール 6:30 起床。まずはコーヒーを淹れながらニュースとSNSチェック 7:00 朝食(自作のオートミールorトースト)、ブログの下書きや記事ネタ整理 8:00 出勤準備 8:30 電車で通勤(この間にポッドキャストやオーディオブックでインプット) 9:15 出社。午前は資料作成やメール返信 12:00 ランチはオフィス近くの定食屋かカフェ 13:00 午後は会議やマーケティング企画立案、データ分析 18:00 退社 19:00 帰宅途中にスーパー寄って買い物 19:30 夕食&YouTubeやNetflixでリラックスタイム 21:00 ブログ執筆や写真編集、次の記事の構成作成 23:00 読書(比較記事のネタ探しも兼ねる) 23:45 就寝準備 24:00 就寝
リクエストヘッダとリクエストボディの違いを知ろう
HTTPのしくみはとてもシンプルに見えますが、実は中身が細かく分かれており、データをどこにどのように置くかで意味が変わります。ウェブサイトに何かを依頼するとき、まず「リクエストライン」があり、続いて複数の「リクエストヘッダ」が並び、必要であれば「リクエストボディ」が続きます。
ここで大事なのは、ヘッダはデータの性質や送る情報の意味を伝える役割、ボディは実際の情報そのものを運ぶ役割という点です。例えばログイン画面にユーザー名とパスワードを送るとき、名前とパスワード自体はボディの中に入ります。一方でサーバーに「このリクエストはどのアプリケーションを使っているか」「どの言語で表示すべきか」といった情報はヘッダに入れます。ヘッダは軽く、ボディは容量が大きいことが多いのが特徴です。
では、具体的にどう違うのかを次の見出しで詳しく見ていきましょう。
リクエストヘッダとは何か
リクエストヘッダは、サーバーへ伝えたい情報の“枠組み”を決める役割を持ちます。ここにはHTTPメソッド(GET, POST など)、リクエスト先のURLの解釈に必要な情報、サーバー側がどう対応するかを決めるヒントが詰まっています。代表的な例として以下のようなものがあります。
Hostはどのサーバーに送っていいかを示し、User-Agentは使っているブラウザやアプリの情報を伝えます。Acceptはどんなデータを受け取りたいか、Content-Typeはボディの中身の形式を知らせます。なお、空のボディでもヘッダは必ず存在しますことがあり、GETリクエストでは特に多くのヘッダが用いられます。ヘッダは「メタデータ」を運ぶ箱のようなもので、実際のデータ本体はボディに入ることが多いのです。
リクエストボディとは何か
リクエストボディは、実際のデータを運ぶ部分です。GETのようにデータを送る必要がない場合や、検索語などをURLのクエリ文字列として渡す場合にはボディは使いませんが、POSTやPUTの場面では必ずと言っていいほど使われます。ボディの内容は「何を送るか」という情報そのもので、文字列だけでなく、JSON、XML、あるいはファイルデータなど、さまざまな形式が使われます。
このボディを正しく解釈してもらうためには、Content-Typeというヘッダの情報が不可欠です。たとえば Content-Type: application/json ならボディはJSON形式として読み取られ、Content-Type: multipart/form-data ならファイルやフォームのデータを複数のパートに分けて送ることを意味します。ボディのサイズはContent-Lengthヘッダで決まります。
このようにボディは「送るデータそのもの」を含む箱であり、ヘッダはそれをどう扱うかを指示する箱だと理解するとわかりやすいです。
実務での使い分けと注意点
実務では、リクエストヘッダとリクエストボディをどう組み合わせるかが、アプリの動作速度とセキュリティに直結します。
まずデータの性質を考え、機密情報や計算量の多いデータはボディに含めるべきかを判断します。ログにも記録されるのはヘッダ情報が多いので、機微情報をヘッダに載せると不要な露出が増える可能性があります。認証トークンやセッション情報はヘッダのAuthorizationに入れることが多いですが、これが漏れると深刻な被害につながることがあります。反対に、入力フォームのデータや設定データのような大量のデータは、ボディに入れて送るのが自然です。
また、Content-TypeとContent-Lengthの組み合わせは必ず正しく設定しましょう。誤ったContent-Typeはサーバーの解釈を狂わせ、セキュリティ上のリスクを引き起こすことがあります。テスト時にはcurlコマンドやPostmanなどのツールを使って、ヘッダとボディがどのように分かれて送られるかを確認すると安全です。
ボディのデータを圧縮する場合には、Content-Encodingヘッダを使います。まとめると、ヘッダは伝える情報の枠組み、ボディは実際のデータそのものを運ぶという基本原則を覚えておくことが大切です。
よくある誤解とFAQ
よくある勘違いを正しく理解しておくと、APIの設計やデバッグが楽になります。例えば「ヘッダに情報を詰め込むほど速くなる」という考えは間違いです。ヘッダには容量制限があり、過剰な情報を入れるとサーバーが処理しづらく、ログの肥大化にもつながります。逆に「ボディが空だと意味がない」という考えも違います。GETリクエストではボディを送らないのが普通ですが、サーバーサイドの仕様によってはボディを受け付ける場合もあります。実務では、APIの仕様書をよく読み、どのデータをheaderに置き、どのデータをbodyに置くかをチームで統一します。
以下の表は、ヘッダとボディの基本的な違いを一目で比べるのに役立ちます。
リクエストヘッダは封筒の役割のようなもの。宛先や発送元、受け取り方のルールを伝える箱で、実際の中身(データ)は別の箱に入る。リクエストボディは封筒の中身そのもの、つまり送るデータそのもの。ヘッダとボディは別々に送られ、用途と扱い方が異なるため、設計やデバッグの際にはこの分け方をしっかり理解することが大切です。日常生活の手紙に例えるなら、封筒の住所と差出人がヘッダ、手紙の本文がボディにあたります。必要な場面で適切に使い分けることで、安全で効率的な通信が実現します。
次の記事: コストベースとルールベースの違いを中学生にも分かる言葉で徹底解説 »