Part 2 開発の基本動作・動画
第7章 Webの仕組みを観察する
動画台本ナレーション全文
Slide 01. Webの仕組みを観察する
Chapter 7では、ブラウザで画面を開いたときに、裏側で何が起きているかを観察します。画面に一覧が出る、ボタンを押す、ログイン状態が続く。こうした普段の操作の裏では、ブラウザとサーバーが何度も通信しています。この章では、その通信をURL、Networkタブ、curl、Cookieという道具で見えるようにします。
Slide 02. この章で持ち帰ること
この章で身につけるのは、Web通信を見る順番です。まずURLを、接続先、対象、条件に分ける。次にNetworkタブで、どの通信が出たかを見る。必要ならcurlで、ブラウザを通さず同じ相手に聞いてみる。最後にCookieとセッションで、ログイン状態がどう保たれるかを見る。この順番があると、画面の不具合を落ち着いて切り分けられます。
Slide 03. 前の章からつなげる
第5章では、ローカル開発サーバーを起動し、URL、ポート、ログを見ました。第6章では、変更をPull Requestで共有する流れを学びました。第7章では、画面操作とサーバーのあいだで起きるHTTP通信を観察します。画面で何が起きたかに加えて、どのURLに、どんなリクエストを送り、どんなレスポンスが返ったかを記録し、相談やPRに使える材料にします。
Slide 04. Webは往復で動く
Webアプリでは、ブラウザがサーバーにリクエストを送り、サーバーがレスポンスを返します。HTTPは、HyperText Transfer Protocolの略で、Webで情報をやり取りするための約束ごとです。日常語で言うと、ブラウザからの注文票と、サーバーからの返事の形式です。まずはこの往復を1セットとして見るところから始めます。
Slide 05. 1画面に複数リクエスト
ブラウザで1つの画面を開いても、通信は1回で終わらないことが多いです。最初にHTMLという画面の骨組みを受け取り、その後でCSSという見た目の情報、JavaScriptという動きのためのファイル、画像、APIのデータを追加で取りに行きます。APIは、画面やプログラムがサーバーの機能やデータを使う入口です。画面の一部だけ表示されないときは、失敗したリクエストを探すと原因に近づけます。
Slide 06. URLを分解する
URLは、Uniform Resource Locatorの略で、Web上の住所のようなものです。例は画面に出しているURLです。最初は、httpが通信方法、localhost:3000が接続先、/mentors/progressが対象、filter=unsubmittedが条件、と分かれば十分です。#listはブラウザ内の位置です。
Slide 07. localhostとport
localhostは、自分のPCを指す特別な名前です。第5章で見た http://localhost:3000 は、自分のPCの3000番ポートで動いている開発サーバーを見に行く、という意味です。ポートは、同じPCやサーバーの中で、どの入口に行くかを分ける番号です。アクセスできないときは、サーバーが起動しているか、URLのポート番号が合っているかを分けて見ます。
Slide 08. DNSは名前を探す
DNSは、Domain Name Systemの略で、example.com のような名前から接続先を探す仕組みです。普段は名前だけでサイトを開けますが、実際の通信では、その名前がどの接続先を指すかを調べています。ここではDNSの細かい運用は扱いません。大事なのは、アクセス失敗を、名前から接続先を見つけられない場合と、サーバーにつながった後に失敗する場合に分けることです。
Slide 09. HTTP requestを読む
HTTPリクエストは、ブラウザやcurlからサーバーへ送る依頼です。中には、method、path、headers、bodyがあります。methodはGETやPOSTのような目的、pathは対象、headersは追加情報、bodyは送る中身です。最初は全部を読む必要はありません。まずGETかPOSTか、どのpathか、ヘッダーに秘密情報が入っていないかを見ます。
Slide 10. HTTP responseを読む
HTTPレスポンスは、サーバーからの返事です。よく見るのは、ステータスコード、ヘッダー、bodyです。ステータスコードは、サーバーがリクエストをどう扱ったかを数字で示します。bodyには、HTML、JSON、画像、エラーメッセージなどの本体が入ります。数字だけで決めつけず、bodyやサーバーログも合わせて見ると判断しやすくなります。
Slide 11. methodは目的を示す
methodは、サーバーに何をしたいかを示す言葉です。GETは取得、POSTは作成や送信、PUTやPATCHは更新、DELETEは削除で使われることが多いです。ただし、実際の意味はアプリの設計にもよります。まずは、一覧を見ているのにPOSTが出ている、保存ボタンなのにGETだけ、のように、操作とmethodの関係を観察します。
Slide 12. status codeを見る
status codeは、レスポンスの大まかな結果を示す数字です。全部を暗記する必要はありません。まず、200番台は成功、300番台は別の場所へ案内、400番台はリクエストや権限に近い問題、500番台はサーバー側の失敗に近い問題、と大きく見ます。よく使う例では、401は未ログイン、403は権限不足、404は対象が見つからない、500はサーバー内の失敗です。
Slide 13. Networkタブで見る
ブラウザの開発者ツールにあるNetworkタブを見ると、画面表示の裏で発生した通信が並びます。最初に見るのは、URL、method、status、responseの概要で十分です。HTMLを取りに行くリクエスト、JavaScriptを取りに行くリクエスト、APIのリクエストを1つずつ選びます。画面のどの動きが、どの通信につながったかを見る練習です。
Slide 14. curlでブラウザを通さず見る
curlは、ターミナルからHTTPリクエストを送る道具です。ブラウザを通さずに、サーバーがどう返すかを確認できます。たとえば curl -i http://localhost:3000/mentors/progress と打つと、ヘッダーを含めてレスポンスを見られます。ブラウザで表示されないとき、サーバー自体は返しているのか、ブラウザ側で止まっているのかを分ける助けになります。
Slide 15. ブラウザとcurlの違い
ブラウザとcurlは、同じURLを見に行っても、持っている情報が違うことがあります。ブラウザはCookieや一部のヘッダーを自動で付けます。curlは、指定しない限り、ログイン状態やブラウザの保存情報を持ちません。そのため、ブラウザでは成功してcurlでは401になることがあります。違いが出たら、Cookie、ヘッダー、認証状態を比べます。
Slide 16. Cookieとセッション
Cookieは、サーバーから受け取ってブラウザが保存し、次のリクエストに添える小さな情報です。セッションは、サーバー側でユーザーの状態を扱う仕組みです。ログイン中かどうか、カートに商品が残っているか、といった状態は、この2つと関係します。Cookieの値には秘密情報が含まれることがあるので、提出物やAI入力では必ず伏せます。
Slide 17. エラーを分類する
Web通信のエラーは、段階で分けると調べやすくなります。名前から接続先を見つけられないのか、ポートにつながらないのか、サーバーには届いて404や500が返っているのか。ほかにも、ブラウザが安全上の理由で止めるCORSのエラーがあります。画面だけを見ると全部同じ失敗に見えるので、Networkタブ、curl、サーバーログで段階を切り分けます。
Slide 18. 良いWeb相談
相談するときは、「画面が表示されません」だけだと相手が調べ始めにくいです。たとえば、進捗一覧画面で、HTMLは200、JavaScriptも読み込まれている、GET /api/mentor/learners だけ500、と書くと、見る場所がかなり絞れます。相談文には、画面、操作、失敗したリクエスト、status、試したことを書きます。第7章のHTTP観察結果は、メンターやレビュアーに渡す調査メモになります。
Slide 19. AIにHTTPログを渡す
AIは、HTTPログの要約、エラー分類、次に見る場所の整理に使えます。ただし、リクエストヘッダー、Cookie、Authorizationヘッダー、tokenには秘密情報が含まれることがあります。貼る前に、Cookie: REDACTED のように値を伏せます。個人情報や未公開URLも貼りません。AIの答えは仮説として扱い、Networkタブ、curl、サーバーログで確認します。
Slide 20. 演習1 URL分解
最初の演習では、http://localhost:3000/mentors/progress?filter=unsubmitted#list を分解します。scheme、host、port、path、query、fragmentを表にします。目的は英語名の丸暗記ではありません。接続先、対象、条件を分けて説明できれば十分です。成果物は url-analysis.md です。
Slide 21. 演習2 Network観察
次の演習では、サンプルアプリを開き、Networkタブで通信を見ます。進捗一覧画面を再読み込みし、HTMLを取りに行くリクエスト、JavaScriptを取りに行くリクエスト、APIのリクエストを1つずつ選びます。URL、method、status、responseの概要を記録します。成果物は http-observation-log.md です。
Slide 22. 演習3 curl観察
3つ目の演習では、curl -i でHTTPレスポンスを見ます。ブラウザで確認した画面やAPIのURLに対して、ターミナルからリクエストを送ります。ステータスコード、ヘッダー、bodyの概要を分けて読み、ブラウザで見た結果と比べます。成果物は curl-observation-log.md です。
Slide 23. 演習4 Cookie確認
4つ目の演習では、ログイン前後や疑似ログインでCookieを観察します。Cookieがセットされるタイミング、次のリクエストに付くか、値以外の設定が見えるかを確認します。HttpOnly、Secure、SameSiteは深追いせず、見つけたらメモする程度で大丈夫です。値は提出物に貼らず、REDACTEDと伏せます。成果物は cookie-session-note.md です。
Slide 24. 演習5 エラー分類
最後の演習では、Web通信エラーを分類します。名前から接続先が見つからない、localhostのポートにつながらない、404や500が返る、ブラウザが安全上の理由で止める、といった例を見ます。CORSは、その安全上の理由で止まる例として扱います。それぞれ、どの段階で失敗していそうか、次に見るログやコマンドは何かを書きます。成果物は web-troubleshooting-note.md です。
Slide 25. 次はデバッグへ
第7章では、Webの仕組みを通信として観察しました。URLを読み、Networkタブでリクエストを見て、curlでレスポンスを確認し、Cookieやエラー分類を扱いました。次の第8章では、未提出者フィルタの不具合を題材に、既存コードを小さく読み、原因候補を絞ります。ここで作ったHTTP観察ログは、再現手順、相談文、Pull Requestの説明に使う材料になります。