送った要求への「返事」を読む
D-03では、クライアントからサーバーへ送る要求、HTTPリクエストの中身を上から読みました。要求を送れば、必ずサーバーから返事が返ってきます。今回はその返事、HTTPレスポンスを読みます。要求と応答は必ず対になっていますので、前回が往復の前半、今回はその後半にあたる、と考えてください。
このスライドのポイント
- D-03: クライアントからサーバーへ送る要求＝HTTPリクエストを読んだ
- 要求を送れば、必ず返事が返ってくる
- 今回はその返事＝HTTPレスポンスを読む
- 要求と応答は必ず対になっている（往復の後半）
レスポンスとは何か
レスポンスとは、サーバーからクライアントへ返す応答メッセージのことです。構成は3つで、ステータス行、ヘッダー、ボディに分かれます。ステータス行には、HTTP/1.1という表記と、ステータスコード、そして理由句が並びます。ステータスコードとは、処理の結果を表す3桁の数字のことです。数字ごとの分類はD-06で詳しく扱いますので、ここでは3桁の数字が結果を表す、という点だけ押さえてください。
このスライドのポイント
- レスポンス＝サーバーからクライアントへ返す応答メッセージ
- 構成は3つ: ステータス行／ヘッダー／ボディ
- ステータス行＝「HTTP/1.1」＋ステータスコード＋理由句
- ステータスコード＝処理結果を表す3桁の数字（分類はD-06で詳しく）
なぜレスポンスを読めると良いか
レスポンスを読めないと、不具合が起きたときに「エラーです」としか言えません。どの段階で、誰の原因で失敗したのかを、AIへ正確に伝えられないのです。レスポンスを読めるようになると、報告が「404が返っています」という一言で済みます。この一言があるかないかで、AIによる原因の絞り込みの速さと精度は、大きく変わってきます。
このスライドのポイント
- 読めないと「エラーです」としか言えない
- どの段階で・誰の原因で失敗したかをAIへ伝えられない
- 読めれば報告が「404が返っています」の一言で済む
- この一言の有無で、AIの原因の絞り込みが大きく変わる
レスポンスの構造
レスポンスの構造を見ます。上からステータス行、ヘッダー群、空行、そしてボディの順です。D-03で見たリクエストと同じで、空行が仕切りになり、その下がボディという形は共通しています。違うのは1行目だけです。リクエストの1行目はメソッドとパスでしたが、レスポンスの1行目はステータス行になります。要求と応答が、よく似た形をしていることを掴んでください。
このスライドのポイント
- 上からステータス行→ヘッダー群→空行→ボディ
- D-03のリクエストと同じく「空行が仕切り」、その下がボディ
- 違うのは1行目だけ
- リクエストの1行目＝メソッド＋パス／レスポンスの1行目＝ステータス行
Webアプリでの具体例
具体例で見ます。D-03で送ったお問い合わせフォームの送信に対する、サーバーからの返事です。処理が成功すれば、200という数字とともに、結果のデータがJSONの形でボディに入って返ってきます。フロントエンドはそのボディの中身を見て、画面に「送信完了」と表示します。つまり、画面に出ている表示は、レスポンスの中身から作られているのです。裏側では毎回、この応答が画面へと変換されています。
このスライドのポイント
- D-03のお問い合わせフォーム送信への「返事」
- 成功なら200とともに結果のデータがJSONでボディに入って返る
- フロントエンドはそのボディを見て「送信完了」を表示する
- 画面の表示は、レスポンスの中身から作られている
技術サンプル: 成功レスポンスを読む
技術サンプルを見ます。種別はhttp、目的は、成功したレスポンスの3つの部品を実物で確認することです。1行目の200 OKがステータス行で、ステータスコード200は処理が成功したことを表します。空行の下のボディには結果のデータが入っていて、ここでは受付番号として42が返っています。Content-Typeというヘッダーは、ボディがJSONという形式であることを伝えています。このヘッダーの正式な扱いはD-07で学びます。AIには「このAPIが失敗したとき、どのステータスコードとどんなボディを返す設計ですか」と聞いてみましょう。
混同しやすい概念
混同しやすいのは、ステータスコードと、ボディの中に書かれたエラーメッセージです。ステータスコードは配達そのものの結果、ボディはその中身、と考えてください。設計によっては、ステータスコードが200なのに、ボディの中身がエラー内容になっていることがあります。ですから、成功したかどうかの判定は、ステータスコードとボディの両方を確認する必要があります。片方だけを見て安心しないことが大切です。
このスライドのポイント
- ステータスコード ＝ 配達そのものの結果
- ボディ内のエラーメッセージ ＝ 荷物の中身
- 設計によっては、200なのにボディが
{"error": ...}のことがある - 成功判定は「ステータスコード」と「ボディ」の両方を確認する
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIに通信処理を作らせたら、「成功と失敗をどう見分けていますか。ステータスコードとボディのどちらを見ていますか」と必ず確認してください。そして、エラーを報告するときは、ステータスコードを必ず添えます。D-01で見たとおり、処理の正しさはサーバー側の責任ですが、返ってきた結果を正しく読み取り、AIへ伝えるのは私たち人間の仕事です。
このスライドのポイント
- AIに通信処理を作らせたら成功と失敗の見分け方を確認する
- 質問例: 「成功と失敗をどう見分けていますか。ステータスコードとボディのどちらを見ていますか」
- エラー報告にはステータスコードを必ず添える
- 処理の正しさはサーバー側の責任（D-01で見たとおり）、それを読み取るのは人間の仕事
まとめと一問一答
最後に一問一答です。応答の処理結果を表す3桁の数字を、何と呼ぶでしょうか。少し考えてみてください。答えは、ステータスコードです。30秒まとめです。レスポンスはステータス行・ヘッダー・ボディの3つでできていて、成功判定はステータスコードとボディの両方を見る、これが今回の要点でした。次回のD-05では、要求の種類を表すメソッドの使い分けへ進みます。関連資料は「API連携 超入門」「エラー文の読み方」「API連携ワード100」です。
このスライドのポイント
- 一問一答: 応答の処理結果を表す3桁の数字を何と呼ぶ？ → ステータスコード
- 30秒まとめ: レスポンス＝ステータス行・ヘッダー・ボディの3つ／成功判定は両方を見る
- 次回D-05: 要求の「種類」を表すメソッドの使い分けへ
- 関連資料: 「API連携 超入門」「エラー文の読み方」「API連携ワード100」
