はじめに
本記事の効能
- 最低限知っておくべきHTTPのしくみがわかる
- HTTPという単語にビビる気持ちを和らげる
本記事の対象者
Webアプリ開発を始めた人、基本情報技術者試験や応用情報技術者試験の勉強をしている人
HTTPの全体像をつかむ
HTTPはハイパーテキストをやり取りするために生まれたきまり事です
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World</title>
</head>
<body>
<h1>Hello, World!</h1>
</body>
</html>
正式名称は、HyperText Transfer Protocol といい、ハイパーテキストという形式のデータをインターネット上でやり取りするための仕組みです。ハイパーテキスト とは、複数のテキストを関連付けて、相互に参照できるようにする仕組みであり、HTML (HyperText Markup Language) とよばれるマークアップ言語で記述されます。
弊社のサイトの場合、トップページのヘッダーに 記事一覧 というリンクがあり、クリックすると投稿された記事一覧が表示されます。さらに、特定の記事をクリックするとその 記事の詳細 を確認できます。つまり、本サイトでは、トップページと記事一覧ページと記事詳細ページがリンクで相互に関連付けられているということになります。（ページの仕様は変更されている可能性があります）
皆さんが弊社のサイトにアクセスした際に行ったやり取りがまさにHTTPです。その証拠に、弊社のサイトのURLの先頭に、https と書かれているはずです。（今のところは、HTTPにセキュリティ機能を追加した仕組みだと考えてください。）
HTTPでやり取りするのはクライアントとサーバです
リクエスト(→)
ユーザ(利用者) ---→ クライアント ←------------------------------------→ サーバ
(←)レスポンス
例えば、Webサイトを表示する際には、まず、クライアント（ユーザがブラウザを介してやり取りする）がサーバに対して、「...のページをください！」と リクエスト(要求) を送信します。それに対し、サーバ が「...のページを送ります！」と レスポンス(応答) を送信することでWebサイトを見ることができるのです。これに関して、拙著ですが、「Rails超入門 SessionとCookieの違いって？」という記事を投稿しておりますので、是非ご一読ください。（Railsに触れていない方でも大丈夫です！）
HTTPのおかげで様々なブラウザに対応できます
HTTPのようなきまり事が必要な理由の一つは、異なるブラウザ間での 互換性 を保ち、Webページを正しく表示するためです。皆さんはどのブラウザで本記事をご覧になっているでしょうか。2024年6月における国内のPC用ブラウザのシェアは高い順に、Google Chrome(65.0%)、Microsoft Edge(22.5%)、Mozilla Firefox(5.6%)、Safari(5.0%) となっております。（引用：王道DX - 【2024年6月】Webブラウザシェア率のランキングと推移（日本・世界））
もし、各ブラウザがそれぞれ異なる方法でサーバに通信を要求していたら、サーバ側は大変な負担を強いられることになります。HTTPという 共通規格 のおかげで、異なるブラウザでもスムーズなやり取りができ、Webページは正しく表示されるのです。
やり取りするデータについてより詳しく
HTTPでやり取りするデータはヘッダとボディに分けられます
先ほど説明したハイパーテキストなどのデータは、データに関する説明事項をまとめた ヘッダ とデータの中身である ボディ に分けることができます。宅配便の荷物で例えると、送り状（伝票）がヘッダで荷物本体がボディです。これらについて、実際にブラウザで確認してみましょう。
まずは、ブラウザに搭載されている デベロッパーツール を起動します。Google Chromeでご覧の方は、 F12キー か Ctrl(Command) ＋ Shift(Option) ＋ I を押してください。もしくは、右上のタブでその他のツールをクリックして起動しても構いません。起動すると、このページの要素が表示されていると思います。次に、デベロッパーツールの ネットワークタブ をクリックし、Ctrl + R を押してください。すると、リクエストやレスポンスに関する様々な情報が表示されたかと思います。これらについてもう少し掘り下げてみます。
ヘッダ情報の具体例 - リクエスト編
リクエストヘッダの例（ChatGPTより）
GET /example/path HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Authorization: Bearer abcdef1234567890
GET・POST
リクエストメソッド と呼ばれ、クライアントがサーバに対してどのような要求を送るかを表します。GET は、主にサーバからデータを取得したい場合に使うメソッドであり、サーバに送るデータ（クエリ）はURLの末尾に追加されます。一方、POST は、ログイン時にユーザ情報を送信するなどといったサーバにデータを送信する際に使うメソッドであり、データはボディ部分に記述されてサーバに送られます。
GETとPOSTでデータの送信方法が異なる理由は、リクエストする内容に違いがあるからです。GET で渡すデータは、取得したい情報を識別するためのIDなど、サーバ側で特定の リソースを指定 するために使われます。一方、POST で送信されるデータは、ユーザーの個人情報などの 秘匿性 が高い情報を含むことが多いため、URLに含めずにボディ内で送信されます。これにより、データがURLに直接表示されることを防ぎ、より安全な通信を確保できます。
User-Agent
リクエストを送信しているクライアントのブラウザやOSの情報などをサーバに伝えるものです。例えば、同じURLであるにも関わらず、PCとスマホで表示に違いが生じるようなサイトを見かけると思いますが、この仕組みを実現するために User-Agent の情報が利用されます。また、サイトの運営者側がどの端末で閲覧されているかといった情報を収集する目的でも利用されます。（現在は、個人情報保護の観点からこうした利用を制限する動きがあります。）
Authorization
ユーザ（利用者）の認証情報をサーバに伝えるためのものです。サーバはこの情報からユーザのアクセスを許可してよいかを判断します。そのため、認証 が必要なサイトとやり取りをする際にこの情報がヘッダに含まれていないとアクセスが拒否されてしまいます。
ヘッダ情報の具体例 - レスポンス編
レスポンスヘッダの例（ChatGPTより）
HTTP/1.1 200 OK
Date: Wed, 13 Oct 2024 14:56:29 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure
Server: Apache/2.4.41 (Ubuntu)
ステータスコード
クライアントのリクエストが成功したかどうかを示すためにサーバが送信するものです。これに関してはWebアプリ開発等で特に重要となる知識であるため、より詳しく説明します。
まずは、ざっと次の表を確認してみてください。
| ステータスコード | 意味 | 補足（サーバの反応） |
|---|---|---|
| 1xx | 情報 | まだリクエストを受け入れているよ |
| 2xx | 成功 | ちゃんとリクエストを受理できました！ |
| 3xx | リダイレクト | 他へ移ることを検討してね |
| 4xx | クライアントエラー | リクエスト自体がおかしいよ |
| 5xx | サーバエラー | うまくリクエストを処理できない |
100 Continue
リクエストの処理が完全に終了していないことを示すコードです。
例えば、大容量のデータをサーバに送る際、データは小さなパケットに分割されて送信されます。最初のパケットがサーバに届いた時点で「データを全部受け取ったら処理を続けるよ」と知らせるためにこのコードを返します。サーバは引き続きデータの送信を待っている状態です。
200 OK
リクエストが正常に処理されたことを示すコードです。「ニヤリOK」と覚えてください。
301 Moved Permanently
リクエストされたリソースが永久に別の場所に移動したことを示すコードです。この時、元のURLにアクセスすると自動的に新しいURLへと転送されます（リダイレクト）。
要は、荷物の送り状の住所は引っ越し前のものだから、新しく引っ越し先の住所を案内するということです。
400 Bad Request
リクエスト内容に問題があることを示すコードです。
例えば、リクエストの形式が間違っていたり、必要なデータが不足している場合に発生します。外部APIを利用する際によく遭遇するのではないでしょうか。
401 Unauthorized
認証が必要なリソースにアクセスしようとしたが、正しい認証情報が提供されなかったときに返されるコードです。
例えば、パスワードを間違えたり、トークンの有効期限が切れていたりした場合に返されます。
404 Not Found
リクエストされたリソースが存在しないことを示すコードです。
例えば、指定されたURLが間違っているか、そのページが削除されている場合に返されます。多くの人が一度は目にしたことがあるのではないでしょうか。
500 Internal Server Error
サーバ側で問題が発生し、リクエストを正常に処理できなかったことを示すコードです。
例えば、プログラムにバグがあったり、予期しないエラーが発生したときに返されます。
503 Service Unavailable
サーバが一時的に利用できない状態にあることを示すコードです。
例えば、メンテナンス中や、アクセス集中によりサーバが過負荷状態になっているときに返されます。
Content-Type
やり取りするデータの形式を示すものであり、クライアントがデータの処理方法を判断する時などに使用されます。例えば、冒頭で示した Hello,world! を表示させるHTMLの場合、Content-Type がtext/html であればブラウザに大きく Hello,world! と表示されますが、text/plainの場合はHTMLに記述されたコードそのものが表示されます。
Content-Typeの具体例
| Content-Type | 形式 |
|---|---|
text/html |
HTMLファイル |
text/plain |
テキストファイル |
application/json |
JSONファイル |
application/pdf |
PDFファイル |
image/jpeg |
JPEGファイル |
audio/mpeg |
MP3ファイル |
終わりに
私がWebアプリ開発の世界に飛び込んで数週間が経った時に遭遇したエラーがまさにこれでした。何度修正しても400 Bad Requestはログから消えないし、うまくいったと思ったら、401や500が出現してきて泣きそうになったのを覚えています。初学者なので、知りたい情報が何であるかを即座に把握するのが困難であり、全くエラーと関係のない内容の記事を読み漁ったりしていた時もありました。この記事は、HTTPに関わる人が最優先に知っておくべき内容を厳選して詰め合わせたものです。読破することで、エラーへの対処法自体がわかるようになる訳ではないですが、エラーを解決するためにどのような知識を取り入れるべきかという見通しを立てられるように（若干）なれたと思います。
また、本記事は応用情報や基本情報を受験する方も読者の対象としておりますが、正直、ここまで細かい知識は問われないと思います。（OSI参照モデルの方がはるかに重要です）ただ、少しHTTPの世界を深掘りすることによって、点の知識が線で結ばれたのではないかと思います。
最後までお読みいただきましてありがとうございました。
Discussion