Code and Curls

ひとりごとから始めます。

HTTP Headerについて

この記事は?

経験の浅いチームメンバーから、HTTP Headerについて質問されたときに答えたことをメモ。 REST APIのリファレンスを見ながら、ちょっと困っていた様子。

回答した内容

以下の通り、回答したところ、雰囲気は掴めたようだった。よかった。

外観として

よくある例で、HTTPでの通信(リクエスト/レスポンス)を手紙として表現してみる。 ブウラウザからウェブサイトにアクセスするとき、 ブラウザは実際にはWebサーバーに手紙を書いて送り(GETリクエストを送り)、Webサーバーから手紙(レスポンス)を受け取る。

この手紙には大きく分けて2つの部分がある。

「封筒」と「手紙の中身」。

「手紙の中身」は、実際にWebサイトのコンテンツ(テキストや画像、音声など)です。これはHTTP Bodyと呼ばれる。

一方、「封筒」の部分がHTTP Headerと呼ばれる。 現実では、封筒には送り先の住所や差出人の住所、切手(料金)などが書かれている。 これと同じように、HTTP Headerには、送り先や差出人(どのWebサイトからきたのか、どのブラウザを使っているのかなど)、 どんな形式のデータが含まれているのか(HTML, JSONなど)、データのサイズ、キャッシュの設定など、実際のデータ以外の情報が書かれている。

このようにHTTP Headerは、インターネット通信の際にブラウザとウェブサーバー間で送られる情報の一部であり、 具体的なデータの内容ではなく、データの送り手や形式、設定等の情報を含んでいる部分といえる。

例えば、REST APIでよく登場するのはAuthorizationContent-Typeなどだと思われる。 これも上記の手紙のコンテキストで解説してみる。

Authorizationについて

これは、その名の通り、認証情報を送るための項目。 特定の情報に対するリクエストに対して、レスポンスを返していいのか、を判断する鍵情報となる。 basic XXXX とか、bearer XXXXX. とか、様々な書き方をするが、これが「認証スキーム」と呼ばれている。

よく使うものだと以下のような物がある。

  • Basic認証スキーム

    • ユーザー名とパスワードをコロンで結合し、Base64エンコードしたもの。
    • 容易にデコードできる形式で送信されるため、通信は必ずSSL/TLSなどの方式で暗号化する必要がある。
  • Bearer認証スキーム:

    • OAuth 2.0の認証フレームワークでよく使われる。
    • クライアントはここで、「トークン」を提供します。
    • そのトークンは認証サーバーから取得する。(トークンを取ってからアクセスしなきゃ、とかアクセストークンが腐ってる、とか言ってたらこのあたりのこと)

Content-Typeについて

このヘッダーは、手紙の中身(HTTPボディ)がどのような形式で書かれているかを伝える Webサイトの情報がどのような形式(HTML, JSON, XMLなど)で書かれているかをブラウザに伝える。 ブラウザはこの情報を基に、正しくデータを解釈して表示する。 その逆で、REST APIの利用者がエンドポイントに対し、リクエストボディを送る場合、どのような形式のリクエストなのか、を Content-Typeとして記述する必要がある

締め

その他にも様々な HTTP Headerがある。 また、独自のヘッダーが定義されているケースもあるので、 利用者側は提供者が求める仕様を確認してリクエストする必要がある。 逆に提供する側の場合は、セキュリティに関連するヘッダー等を付加する必要があるなど、確認・設計する必要がある。

とかなんとか、そんな感じで回答しました。