teacher asking a question to the class
Photo by Max Fischer on Pexels.com

【授業レポート】システム開発(3年) 第43週目

〜はじめてのAPI実装:リクエストとレスポンスを体験する〜

第43週目は、先週学んだAPIの基礎知識をもとに、実際に外部APIを呼び出すハンズオン実習を行いました。
「読む」から「使う」へ進む週となり、生徒たちは外部サービスと通信する手応えを初めて体験しました。


■ 先生の導入:「今日は“外と話すコード”を書く日」

田中先生:「今日は、初めて自分のコードが“学校の外”と通信します。
大事なのは、成功だけでなく“失敗したときにどうなるか”をちゃんと見ることです。」

先生は、今日の実習では

  • APIキーは学習用のものを使う
  • 仕様どおりに呼んでも、必ず成功するとは限らない
    という前提を改めて確認しました。

■ 今日のゴール

  1. HTTPリクエストをコードで送れるようになる
  2. APIレスポンス(JSON)を受け取り、必要な情報を取り出す
  3. エラー時のレスポンスを確認し、例外処理を入れる
  4. API呼び出しを Service 層に組み込む感覚を掴む

■ 実習①:APIドキュメントの再確認

最初に、宿題で調べてきたAPIを各自確認。

  • エンドポイント(URL)
  • HTTPメソッド(GET / POST)
  • 必須パラメータ
  • レスポンス例
  • エラーコード(400 / 401 / 404 / 500 など)

生徒A:「ドキュメントをちゃんと読まないと、呼び出せない理由が分かった」

先生は「API実装の半分はドキュメント読解」と強調しました。


■ 実習②:シンプルなAPI呼び出しを書いてみる

Python を使い、最小構成で API を呼び出すコードを書きました。

学習用サンプル(概念理解)

import requests

url = "https://api.example.com/weather"
params = {"city": "Tokyo"}

response = requests.get(url, params=params, timeout=5)
response.raise_for_status()  # HTTPエラーを例外にする

data = response.json()
print(data)

ここで確認したポイント:

  • URL とパラメータが正しく送られているか
  • ステータスコード(200 / 400 / 401 など)
  • JSON が辞書として扱えること

生徒B:「printしてみると、想像以上にデータが多い!」


■ 実習③:必要なデータだけを取り出す

次に、レスポンス全体から必要な項目だけを使う練習。

temp = data["current"]["temp"]
condition = data["current"]["condition"]
print(f"現在の気温:{temp}℃ / 天気:{condition}")

先生のアドバイス:

  • 画面に出すのは「今必要な情報だけ」
  • APIレスポンスの構造が変わる可能性を意識する

生徒C:「JSONを読む力が、設計力につながってる気がする」


■ 実習④:エラーをわざと起こしてみる

APIは常に成功するわけではありません。
そこで次のようなケースを意図的に試しました。

  • パラメータを間違える
  • APIキーを外す
  • 存在しないURLを指定する
try:
    response = requests.get(url, params=params, timeout=5)
    response.raise_for_status()
except requests.exceptions.HTTPError as e:
    print("HTTPエラーが発生しました")
except requests.exceptions.Timeout:
    print("タイムアウトしました")
except Exception as e:
    print("予期しないエラー:", e)

生徒D:「エラーが出ても、プログラムが止まらないのが大事なんだ」


■ 実習⑤:Service層にAPI呼び出しを移す

最後に、2年生で学んだ設計を活かし、
API呼び出しを Service層(ExternalService) に切り出しました。

UI
 ↓
WeatherService
 ↓
WeatherApiClient
 ↓
外部API

ポイント:

  • UIから直接APIを呼ばない
  • Serviceで失敗時の判断をする
  • 将来APIを差し替えられる構造にする

生徒E:「2年生の設計がここで効いてくるとは思わなかった!」


■ クラス全体の気づき

  • APIは「便利」だが「不安定」
  • エラー処理を書かないと、すぐに落ちる
  • レスポンスは全部使わなくていい
  • 設計してから実装すると迷いが少ない

■ 先生のひとこと

「今日、皆さんのコードは初めて“外の世界”と会話しました。
APIを使うということは、自分で制御できないものを扱うということです。

だからこそ、
2年生で学んだ“責務分離・例外処理・ログ”が、
ここで本当の意味を持ってきます。」


■ 宿題(次週に向けて)

  1. 今日使った API を Service クラスに整理して提出
  2. 成功時/失敗時の挙動を文章でまとめる
  3. APIが使えなかった場合のフォールバック案を1つ考える

■ 来週の予告:API連携をアプリに組み込む

次週は、
取得したAPIデータを 自分たちのアプリのユースケース に組み込みます。
「呼べた」から「役に立つ」へ進む段階です。


第43週目は、
生徒たちのシステムが初めて“学校の外”とつながった記念すべき回でした。
戸惑いながらも、API連携の可能性と難しさを実感し、
3年生らしい学びが本格的に動き出しています。

投稿者 greeden

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)