おさわです😆
4月から新しい環境になりました！
その中で、新たな挑戦としてインフラの理解を深めようと思います。
このシリーズは、その私のアウトプットとして書きます。
もう既知の知識もありますが、ネットワークの基礎から固めていきたいので、復習も兼ねて言語化していきます！！！
HTTPメッセージの構造を解剖する
❶HTTPメッセージの全体像
HTTP通信は、ブラウザから送る 「リクエスト」と、サーバーから返ってくる「レスポンス」のセットで成り立っています。どちらも構造は似ており、大きく3つのパーツに分かれます。
- スタートライン: 「何をしたいか（リクエスト）」または「どうなったか（レスポンス）」の1行
- ヘッダー: 通信に関するメタ情報（データの形式、送り主、キャッシュ設定など）
- ボディ: 実際のデータ本体（HTML、JSON、画像など）
❷リクエストメッセージの解剖
ブラウザがサーバーにお願い（リクエスト）をするときの形式です。
スタートライン（Request Line）
GET /api/users HTTP/1.1 のように構成されます。
- メソッド: GET（取得）、POST（作成）、PUT / PATCH（更新）、DELETE（削除）など
- パス: /api/users などのリソースの場所
- バージョン: HTTP/1.1 や HTTP/2
重要なリクエストヘッダー
- Host: 接続先のドメイン名（例: example.com）
- User-Agent: ブラウザの種類やOSの情報
- Accept: ブラウザが受け取れる形式（例:
application/json） - Authorization: ログイン状態を示すトークンなど
❸レスポンスメッセージの解剖
サーバーがブラウザに応える（レスポンス）ときの形式です。
スタートライン（Status Line）
HTTP/1.1 200 OK のように構成されます。
- ステータスコード:
- 200系: 成功
- 300系: リダイレクト（別の場所へ行ってね）
- 400系: クライアント側のミス（URLが違う、権限がないなど）
- 500系: サーバー側のミス（プログラムが落ちたなど）
重要なレスポンスヘッダー
- Content-Type: 返したデータの正体（例:
text/html,application/json）。これがズレるとブラウザが正しく表示できません - Set-Cookie: サーバーから「これを保存しておいて」というクッキーの指示
- Access-Control-Allow-Origin: CORSに関連する、フロントエンドエンジニアが最も遭遇するヘッダーの一つです