コンテンツにスキップ
Twin:te 勉強会 2026

Phase 1: 続! HTTP探検隊

これまで実践編で取り上げてきた内容では、「匿名」掲示板が題材のため、 ユーザ認証が存在しませんでした。 しかし実際のWebアプリケーションを思い浮かべてみると、SNSでもオンラインショッピングでも、 ユーザを登録して、パスワードやメールアドレスなどを使って登録したユーザとしてログインしますよね。

ユーザの認証、認可は極めて高度な話題であり、部品となる技術を正しく理解し実装するのは難しいです。 ここでは、それらすべてや具体の実装方法には触れませんが、

ベースの概念が理解できた、もう少し調べれば実装できそう、と思ってもらえるように、 また、基礎となる考え方をこういう風に持ってほしいというポイントを示せるように説明します。

まず、このPhaseではHTTPについてもう少し詳しく覗いてみましょう。

HTTPの中身を覗いてみよう

1章でHTTPについて触れましたが、今回は実際に生のHTTPを観測してみます。

なお、2章 付録2にその他のHTTPの送受信方法を追記したので、そちらも参考にしてください。

curl で覗く

-v フラグをつけると、HTTPのやり取りがそのまま表示されます。

Terminal window
$ curl -v http://localhost:3000/health

実行すると、以下のようなものが表示されるはずです。

* Connected to localhost (127.0.0.1) port 3000
> GET /health HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/8.x.x
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Vary: Origin
< Date: Sat, 07 Jun 2026 00:00:00 GMT
< Content-Length: 42
<
{"status":"ok","message":"Hello, World!"}

> がリクエスト(送った内容)、< がレスポンス(返ってきた内容)です。

ヘッダというのが、本文(ペイロード)の前にズラッと並んでいますね。

それぞれは キー: 値 の形をしています。

  • Content-Type — データの形式。application/json なら JSON、text/html なら HTML です
  • User-Agent — リクエストを送ったクライアントの自己紹介 (curl/8.x.x, Mozilla/5.0 … など)
  • Date — レスポンスが生成された日時

ヘッダには「取り決められたもの」と「任意に追加できるもの」があります。 リクエスト・レスポンスのどちらにも付けられ、本文とは独立した制御情報の置き場と考えると分かりやすいです。

ブラウザの開発者ツールで見てみよう

ブラウザでもHTTPを観測できます。

F12 (または<Ctrl> + <Shift> + i, または右クリックして「検証」を開く) で開発者ツールを開き、 Networkタブに移動してください。

ページを開いたりボタンを押したりすると、通信のたびに行が追加されていきます。 その行をクリックすると、Request Headers と Response Headers が確認できます。

実際に Twitter(X) や GitHub などでログインした状態でNetworkタブを眺めてみてください。

APIへのリクエスト/レスポンスに、様々なヘッダが付いていることが分かりますね。

特に注目したいのは次の2つです。

リクエストヘッダに Cookie: というヘッダが付いていることがあります。

Cookie: session=eyJhbGciOiJSUzI1NiJ9...; theme=dark

そうです、

Cookieを受け入れますか?

とよく聞かれることでおなじみのCookieです。

Cookieとは、ブラウザがサーバから受け取って、以降のリクエストに自動で付け足してくれる小さなデータです。

流れはこうです。

  1. サーバがレスポンスに Set-Cookie: session=xxx というヘッダを含める
  2. ブラウザがそれを保存する
  3. 以降、同じドメインへのリクエストには自動で Cookie: session=xxx が付く

「自動で付く」というのがポイントです。 クライアントの開発者やユーザが意識しなくても、一度サーバによってSet-Cookieされるとブラウザが毎回持参してくれるわけです。

これによって、アプリケーションのサーバは、 このクライアントはこれまで何にアクセスした、とか、UIのテーマはどれを設定した、とか、 クライアントは誰であるという認証情報、といった制御情報を扱うことが出来ます。

Authorization というヘッダ

もう一つよく見るのが Authorization: ヘッダです。

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Bearer の後ろにある長い文字列がアクセストークンと呼ばれるものです。

「このリクエストを送っているのは、このトークンを持っている人物だ」ということをサーバに伝えるための情報です。

CookieとAuthorizationヘッダ、どちらもトークンを運搬する手段として使われています。 どちらを使うかはシステムの設計によります。

次のPhaseでは、このアクセストークンが何者で、どのように信頼されているのかを見ていきます。