HTTPリクエストとステータスコードの正体
6分08秒 | HTTPWEB
基本情報技術者試験の頻出テーマを解説した音声コンテンツです。
トランスクリプト(字幕テキスト)
ウェブサイトをクリックした瞬間、実はあなたのブラウザとウェブサーバーが目に見えないメッセージを交換してるんですよね。 これってなんだか活気のあるレストランで、ウェイターと厨房がやり取りしてるみたいだなって。 へー!今回は、その隠れた会話の正体を掘り下げていきましょうか? お願いします。 あなたが送る注文、つまり HTTP リクエストと、サーバーから返ってくる3桁の数字の返事、HTTP ステータスコード。 今回は複数の開発ブログや技術解説書を横断して、このウェブの裏側で何が起きているのか、その本質に迫っていきたいと思います。 さっそくなんですが、そのブラウザが送る注文、GET と POST が基本だって聞きました。GET がメニューを見せてっていうのは、うん、すごくイメージしやすいです。 はいはい。でも、例えば会員登録とかで、名前とか住所とかたくさん入力する時ってあるじゃないですか。 あれってもっとこう、複雑な注文書を送ってる感じがするんですが、それが POST っていうことなんですか? まさにその通りです。いや、素晴らしい着眼点ですね。GET っていうのは、URL にこの情報をくださいって書くだけの、まあいわば口頭注文なんですよ。 あ、口頭注文。ええ、手軽ですけど、個人情報みたいな大事な内容は丸見えになっちゃう。 一方で POST は、情報をちゃんと封筒に入れて渡すようなイメージです。 なるほど、封筒に入れるかどうかですか。そうです。フォームに書いたたくさんのデータを安全にサーバーへ送るための注文方法、というわけです。 分かりやすいです。最近のウェブアプリだと、投稿を編集したり、アカウントを消したりもしますよね。そういう操作はまた別の注文になるんですか? ええ、情報を丸ごと更新する PUT とか、あとは削除するための DELETE といった、より具体的な注文方法もありますね。 現代のアプリケーションは、こういう色々な動詞を使い分けて、複雑なやり取りを実現しているわけです。 そしてその注文に対してサーバーから返事が来ると。データそのものと一緒に、必ず3桁の数字が返ってくるんですよね。 その通りです。その数字ステータスコードが、注文がどう処理されたかを示す、ものすごく重要な信号になります。最初の数字で大まかな意味が分かるようになってるんですよ。 ほうほう。200番台は成功。あなたの注文は完璧に処理されましたという合図です。 で、400番台はクライアント側のエラー。つまりお客様、ご注文内容に相違がございますと。 なるほど。そして 500番台がサーバー側のエラー。申し訳ありません、厨房で問題が発生しましたというわけですね。 あ、500番台はエンジニアが真っ青になるやつですね。500 Internal Server Error が出ると、まさに厨房で火事みたいだ。 私も昔深夜にこの 500番エラーで叩き起こされたことありますよ。原因はデータベースのたった一個の設定ミスで、まあまさに厨房でボヤ騒ぎでした。 うわあ、大変でしたね。ええ。ところでその 400番台について一つ面白い点があるんです。 と言いますと? 400番台がお客さん側のミスっていうのは分かります。でも例えば 404 Not Found、 ページが見つからないのって、ページを用意してないサーバー側の問題じゃないんですか? ああ、いい質問ですね。 なんでこれがクライアントエラーに分類されるのか、ちょっと腑に落ちないというか。それはですね、存在しない住所宛に手紙を送ったのは送った側の責任という考え方なんですよ。 あ、なるほど。サーバーからすれば、あなたが指定したページはうちにはないのでお渡しできませんと、あくまでリクエストした側に原因があると解釈されるわけです。 そういう理屈だったんですね、スッキリしました。そして特に重要なのが、よく混同されがちな 401 と 403 の違いです。これをクラブの用心棒に例えてみましょうか。 用心棒ですか? ええ。401 Unauthorized は入り口で会員証を見せてくださいと言われている状態。あなたはまだ誰でもない、つまりログインしていないんです。 はいはい。じゃあ一方の 403 Forbidden は? こちらは会員証を見せて本人確認は済んだものの、申し訳ないですがあなたの会員ランクでは VIP ルームには入れませんと断られる状態です。 ああ、ログインはしてるけどその操作をする権限がない。認証は OK、でも認可は NG というわけですね。 へえ面白い。認証と認可の違いってセキュリティに直結しますもんね。そう考えると、この数字って単なるエラー表示じゃなくて、もっと深い意味があるように思えてきました。 まさに。かつては人間がエラーページを見るためのものでしたが、今やアプリケーション同士が会話するための共通言語になってるんです。共通言語。 ええ。例えばスマホの SNS アプリが新しい投稿を読み込むとき、サーバーに GET リクエストを送ります。その返事が 200 OK なら投稿を表示するし、 401 ならログイン画面に飛ばすとか。この数字を元にプログラムが次の動きを決めている。現代のウェブサービスは、この厳密なルールの土台の上に成り立ってるんですよ。 ということは、ウェブ上のやり取りって GET や POST といった注文と、200番台の成功、400番台のあなたのミス、500番台のサーバーのミスといったステータスコードによる、 極めて整然とした会話なんですね。ええ。そして最後にあなたに一つ問いかけを。この会話のルールも常に進化しています。 スタティックなページを見るだけだった時代から、動画配信やリアルタイム通信が当たり前になった今、より高速で効率的な会話のために、 HTTP/2 や HTTP/3 といった新しいプロトコルが生まれました。これは古いトランシーバーから、多数のチャンネルを同時に使える最新の通信システムへ乗り換えるようなものです。 では、次世代のウェブでの会話には、一体どんな能力が求められるようになるのでしょうか。
このコンテンツは Web society で視聴・学習できます。